精华内容
参与话题
问答
  • 一个人的企业安全建设之路

    千次阅读 2019-03-25 15:11:38
    如今很多中小型互联网公司对安全需求不高,安全资源贫乏,领导只重视业务忽略安全,在这种情况下可能安全人员很难立足,推动公司做好安全,从而进入了进退两难的窘境,目前从事国内某车联网公司,公司团队在300人...

    前言

    如今很多中小型互联网公司对安全需求不高,安全资源贫乏,领导只重视业务忽略安全,在这种情况下可能安全人员很难立足,推动公司做好安全,从而进入了进退两难的窘境,目前从事国内某车联网公司,公司团队在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、安全文章:如果公司有内刊的话可以写几个安全科普的文章,虽然很多人不看,但领导偶尔闲暇会瞄一眼,不要放过任何一个角落与机会,包括此文也希望更多中小型企业借鉴推广,希望提供参考价值。

    展开全文
  • 企业安全管理(一)

    2018-03-08 10:57:06
    2015/06/01 13:160x00 安全行业的第三流派-CSOs目前在大多数行业后加入者的眼中“二进制”和“脚本”流派广为人知,虽然他们是安全行业的主力军,但除了微观对抗之外安全是一个很大的工程,比如企业安全管理,...

    ayazero · 2015/06/01 13:16

    0x00 安全行业的第三流派-CSOs


    目前在大多数行业后加入者的眼中“二进制”和“脚本”流派广为人知,虽然他们是安全行业的主力军,但除了微观对抗之外安全是一个很大的工程,比如企业安全管理,我把他们归入安全行里的第三流派-CSOs,加了s跟scriptkids一样表示他们是一个群体,这个群体从生态链的顶端链接着绝大多数从业者和安全厂商。

    企业安全是不是发现漏洞然后修漏洞,再设置一下防火墙之类的?

    假如你的公司只有一个产品,只有2台服务器,只有3个程序员写代码,我认为这个说法不能算错。不过在绝大多数情况下,企业安全远不止于此。渗透性测试和对抗能不能算企业安全?在一个过于纸上谈兵的企业我觉得这是不错的切入点,不过局部对抗发生于企业安全的各个场景中,他只能算是缩影,不是全貌。企业安全是什么对传统乙方安全公司,对新兴的业务安全公司移动安全公司,对甲方的互联网公司,对甲方的传统公司,对咨询顾问,对漏洞研究者,对活跃于各大SRC上的白帽子们的诠释肯定都不一样。

    先说一下我自己的经历,以便了解我是从什么角度来看待这一问题的,学生时代跟现在的很多白帽子一样玩玩渗透,玩玩二进制,在过去那个叫幻影(Ph4nt0m)的组织里,大学毕业后即进了绿盟做安全服务和咨询,这是乙方中离甲方安全最近的职能,接受了绿盟对传统安全体系和方法论教育,有些10年前的东西放到今天都还会觉得很高大上,现在的安全行业里除了显得有些空洞的安全标准的传承,要么就是很浅的木桶理论之类的外延的理解,尤其在遇到互联网崛起时,攻防受追捧,有些东西因为没有收到金钱的认可很多人就直接把这一部分东西给扔了或自我否定了,其实有些思想跟技术表现形式一点关系都没有,放到今天仍然是很实用的技能。

    在绿盟最大的便利并不是下班路上随便都能找到能聊exploit技术的大牛,而是视野:从金字塔视角看到安全的整体解决方案,囊括组织、管理和技术3方面的东西,覆盖全行业全价值链过程的技术方案,算上第三方的话几乎涵盖市面上所有的安全产品和解决方案。有人看到这些会问这不是传统安全那一套吗?我说且不急,听我慢慢讲,而且我可以剧透的说之后几十篇都是围绕互联网企业安全的,并不打算在传统安全上花很多篇幅,只是需要区分一下企业安全实际的状况和某些厂商为了兜售自己的产品而宣扬的概念是有所不同的,大多数厂商都会避开自己的弱项而在市场活动及软文上专注的强调自己擅长的概念。

    离开绿盟后我去了甲方,一家大型网游公司,08年那时将近万台的物理服务器分布于30多个IDC的规模似乎比当时搜狐全站的IDC规模还要大一些,跟现在一样那时候也是社会上的公司普遍缺少安全负责人的时代,我也有幸组建了一支属于自己的安全团队,成为当时少数的安全总监之一,团队的这些人现在遍布互联网行业的半壁江山,且都是安全部门独当一面的骨干。在这段时间我身体力行了从乙方到甲方视角的过渡,从零开始建立安全体系,真正把乙方玩的东西在一家甲方公司落地了,我的方法思路过程跟某些互联网公司不太一样,因为那时候BAT的安全人员大多是毕业后直接去的甲方,一开始就做甲方安全,而我是从乙方到甲方,所以实践上更多了参考了乙方的方法论,除了攻防之外多线并行,直接建立较完整的安全体系,在遇到上海的网游业被腾讯包抄整体沉沦的时候,我也失去了继续深挖甲方安全建设的兴趣。

    之后我去做了一家webgame公司的技术负责人,社会俗名CTO,由安全转向全线技术管理,说实话在这段时间里我并不是特别重视安全,一方面跟自己是安全出身有关,另一方面这确实是屁股决定脑袋的事情,不是安全不重要,而是有很多事情比安全更重要。安全这个事情说白了就是当你有100w的时候拿出2w买个保险箱装它们你觉得值,但你只有2w的时候要拿出8k买保险箱大多数人都会囊中羞涩。这也是我在知乎上回答的那个问题,为什么做安全一定要去大公司的原因之一。我窃以为很多公司的CEO、CTO的对安全重视,翻译过来应该是:被黑是一件很负面的事情,所以想找个人筹建团队打包了,只要不出事他们就不会太想起这事,但不是心理真的认为安全非常重要,也不会当成是一种竞争力,这句话并不是在映射过去,而是当下国内那么多对企业安全负责人的招聘在我看来也就是那么回事。

    之后我去数字公司经历了短暂的时光,再次以乙方的身份拜访了企业级客户,很偶然的发现大多数乙方的顾问或工程师其实都没有真正做过企业安全管理的经验,虽不能把这些直接等价于纸上谈兵,不过确实是乙方的软肋,在竞争性的销售活动中,三下五除二就“把别人说没了”。在甲方企业高层的眼中,攻防这档子事可以等价于我花点钱让安全公司派几个工程师给我做渗透测试然后修漏洞,不像大型互联网公司那样上升为系统化和工程化的日常性活动。

    离开数字公司后我到了全球化的公司-菊花长从事产品线安全,第一个项目是云计算,产品线安全属于甲方安全又跟很多甲方安全不太一样,他比传统意义上的甲方安全介入的更深,覆盖率更高的SDLC,直接导向产品设计的源头,对绝大多数甲方而言你也许在用OS的Dep&ASLR,也许在用各种容器,但你很少会自己去发明轮子,你也许会自己造一个WAF这样的工具,但你可能很少会像微软那样要自己去搞一个EMET这种涉及安全机制层面的东西,但在产品线安全里,这一切都会更进一步,不只是像互联网公司那样关注入侵检测、漏洞扫描等而是从设计和威胁建模的角度去看整体和细节的安全。这又拓展了我从R&D的视角看待以及分析安全问题的眼界。

    至此,我既不属于脚本二进制,我也不属于乙方咨询顾问派,也不单纯属于甲方CSO,而是站在一个较全面客观中立的立场,我不会说某些方式属于纸上谈兵,也不会把攻防捧的至高无上,我认为这些都属于偏激的话。

    好了,切入第一篇的正题,企业安全是什么?

    我认为它可以概括为:从广义的信息安全或狭义的网络安全出发,根据企业自身所处的产业地位、IT总投入能力、商业模式和业务需求为目标,而建立的安全解决方案以及为保证方案实践的有效性而进行的一系列系统化,工程化的日常安全活动的集合。怎么感觉有点咬文嚼字?好吧,这里面的每一个项都会决定你的安全整体方案式什么,哪怕同是中国互联网TOP10中的公司其安全需求也完全不一样。

    有人也许会觉得CSO干的活有点虚,但凡偏管理都是纸上谈兵。我不直接回答这个问题,我只举一个例子。大多数身在这个行业的人都知道社工库遍地都是,入侵者甚至站在了大数据的维度,国内的数据库绝大多数除了password字段加盐值存储,其余信息都是明文保存。而在欧美等地隐私保护是有明确的法律规定的,映射到数据持久化这个细节,就是需要满足一定强度以上的加密算法加密存储,CSO就是需要制定这些策略的人,你难道说这些都是形而上学无用的安全措施么?在互联网公司,安全负责人是会较多的介入到日常的技术性活动中的,但随着组织规模的扩大和官僚程度的加深,CSO不再可能表现的像白帽子一样专注于攻防对抗的细节也是一个无法回避的现实问题。是不是一定要说出诸如CSRF时IE和其他浏览器的区别这样的问题才算是合格的CSO,我觉得这个看具体场景,对于国内排名TOP5以后的互联网公司我觉得这个需求算合理范畴,但对于规模非常庞大的公司而言,这个需求显然太苛刻了,比如我所在公司,CSO属于法务类职位而不是技术类职位。

    不想当将军的士兵不是好士兵,虽然有技术路线,不过我估计这个行业里至少有一半以上人想过要当CSO,但是CSO这个职业又跟某些大牛们表达的不完全一致,所以下面的篇幅会继续写,至少在技术层面,CSO不会只停留在微观对抗,而是会关注系统性建设更多一点。

    0x02 企业安全涵盖哪些事情


    从我在绿盟所受的安全教育来看大致分为以下几方面:

    1. 网络安全:基础、狭义但核心的部分,以计算机(PC、服务器、小型机、BYOD……)和网络为主体的网络安全,主要聚焦在纯技术层面 
    2. 平台和业务安全:跟所在行业和主营业务相关的安全管理,例如反欺诈,不是纯技术层面的内容,是对基础安全的拓展,目的性比较强,属于特定领域的安全,不算广义安全。 
    3. 广义的信息安全:以IT两个字为核心,包括广义上的“Information”载体:计算机数据库意外还有包括纸质文档、机要,市场战略规划等经营管理信息、客户隐私、内部邮件、会议内容、运营数据、第三方的权益信息等但凡你想得到的都在其中,加上泛“Technology”的大安全体系 
    4. IT风险管理、IT审计&内控:对于中大规模的海外上市公司而言,有诸如SOX-404这样的合规性需求,财务之外就是IT,其中所要求的在流程和技术方面的约束性条款跟信息安全管理重叠,属于外围和相关领域,而信息安全管理本身从属于IT风险管理,是CIO视角下的一个子领域 
    5. 业务持续性管理:BCM(Business Continuity Management)不属于以上任何范畴、但又跟每一块都有交集,如果你觉得3和4有点虚,那么BCM绝对是面向实操的领域。最近前有网易、中有支付宝、后又携程,因为各种各样的原因业务中断,损失巨大都属于BCM的范畴。有人会问这跟安全有什么关系?安全是影响业务中断的很大一部分可能因素,例如DDOS,入侵导致必须关闭服务自检,数据丢失隐私泄露等。又会有人问这些归入安全管理即可,为什么要跟BCM扯上关系,做安全的人可以不管这些吗?答案自然是可以不管,就好像说“我是个java程序员,JVM、dalvik(ART)运行原理不知道又有什么关系,完全不影响我写代码!” 事实上BCM提供了另一种更高维度,更完整的视角来看待业务中断的问题,对于安全事件,他的方法论也比单纯的ISMS更具有可操作性,对业务团队更有亲和力,因为你知道任何以安全团队自我为中心的安全建设都难以落地,最终都不会做的很好 
    6. 安全品牌营销、渠道维护:CSO有时候要做一些务虚的事情,例如为品牌的安全形象出席一些市场宣介,presentation。笼统一点讲现在SRC的活动基本也属于这一类。 
    7. CXO们的其他需求:俗称打杂。这里你不要理解为让安全团队去攻击一下竞争对手的企业这样负面向的事情,而是有很多公司需要做,但运维开发都不干,干不了或者不适合干的事情,安全团队能力强大时可以承包下来的部分,事实上我的职业生涯里就做了不少这样的事情。
    复制代码

    基础的网络安全是绝大多数在甲方的安全团队能cover的事情,不管你的安全团队能力如何,在公司里有无影响力,这个是必须要做的因为这是把你招过来的初衷。再往后的发展,是否止于此则看各人的想法,对于沉醉攻防技术的人其实不需要往后发展了这些足够了,但如果你的安全团队富有活力和想法,即便你想止于此他们也不干,把部门做大做强是这些人的愿望,只有这样才能给安全团队更大的空间,因为这点跟乙方是不一样的:对于乙方而言你可以在某个单点领域上无限深挖,而不会遇到天花板,因为你始终是在满足主营业务的需求,即使你成为骨灰级的专家公司也会对你在某方面创新有所期待而给你持续发展的可能性,但是在甲方,安全不是主营业务,归根结底是一个保值型的后台职能,不是一个能创造收益的前台职能,他是一个成本中心而非盈利中心,他的成本的大小跟业务规模以及公司盈利能力相关,公司发展时他的budget和headcount会发展,业务停滞时安全做的再好也不会追加投入,因为无此必要。反面的例子也有:做的不好反而追加投入的,那是一种政治技巧而非现实需要。

    如果你在乙方的研究部,无论你的漏洞挖掘技能多牛逼,公司都不会跳出来说“你已经超出我们需求了,你还是去更NB的公司吧”(通常情况)。但是在甲方,假设是在一个国内排名大约TOP5-TOP10的互联网公司,养一个漏洞挖掘的大牛也会觉得很奇怪,他是在给公司创造价值还是在自娱自乐是会受到质疑的,CSO也会被质疑是否花了大价钱挖来的人不是出于业务需要而是用于扩大自己团队在业内影响力这种务虚的事。假如公司到了google这种级别,有一大堆产品,储备大牛则是顺利成章的,业务上显然是有这种需求的,不过还是要看产出是否对主营业务有帮助,工作成果不能转化为主营业务竞争力的尝试性活动在公司有钱的时候无所谓,在公司收紧腰带时则其存在价值会受到质疑。

    以狭义的安全垂直拓展去发展甲方安全团队的思路本质上是个不可控的想法,筹码不在CSO手中,甚至不在CTO手中,而是看主营业务的晴雨表,也就是我以前微博上说的,甲方安全是要看“脸”的,这个脸还不是指跨部门沟通合作,而是在最原始的需求出发点上受限于他们。因此有想法的安全团队在(1)做的比较成熟时会转向(2),(2)是一个很大的领域,发展的好安全团队的规模会x2,x3,并且在企业价值链中的地位会逐渐前移,成为运营性质的职能,结合BCM真正成为一个和运维、开发并驾齐驱的大职能。

    BCM在很多人眼里就是DR(灾难恢复),DR其实只是BCM中的一个点,属于下层分支。不过这对技术领域的人而言是最直观的部分,DR在互联网公司里由基础架构部门或运维主导,不过对于强势的甲方安全团队其实也是能参与其中一部分的,我之前也主导过这些,当然也是受到了绿盟的教育以及我的“前辈们”的启发。有兴趣的可以看一下BS25999

    广义的信息安全,比较直观的映射就是ISO2700x系列,行业里的绝大多数人都知道ISO27001和BS7799.不展开了,对真正有安全基础的人而言都是很简单的东西。在企业里能否做到广义的安全,主要看安全负责人和安全团队在公司里影响力,对上没有影响力,没有诠释利害关系和游水的能力自然也就做不到这些,另一方面,狭义安全主要对接运维开发等技术面公司同僚,但是广义安全会对接整个公司的各个部门,对于沟通面的挑战来说又上了一个新的台阶,似乎在我看来这主要取决于安全的领队人物自己拥有什么样的知识结构以及他的推动能力如何。

    对于(4),如果你所在的组织有这方面的需求,安全职能自然也会参与其中,是否刻意去发展他则看自己需求,对我朋友中某些做过IT治理和风险咨询的人相信是有能力一并吃下的,如果是技术派我就不建议你去搞了。

    (6)属于水到渠成的事情,到了那一步你自然需要考虑,就算你不想公司也会让你去,就像我现在明明做技术活,却也不知道为啥会跟这一类事情挂上钩。

    (7)有人看时自动过滤了,不过安全负责人自身是否有瓶颈,能否在企业里发展起来跟这条有很大关系,甚至有很多从(1)发展到(2)(3)的人都需要借助(7)这个渠道,点到为止不多说了。。。

    对于互联网公司,我建议做1、2、5;对于传统行业,我建议做:1、3、4、5。

    在互联网行业安全包括哪些内容,我觉得可以概括为: 信息安全管理(设计流程、整体策略等),这部分工作约占总量的10%,比较整体,跨度大,但工作量不多。

    基础架构与网络安全:IDC、生产网络的各种链路和设备、服务器、大量的服务端程序和中间件,数据库等,偏运维侧,跟漏洞扫描,打补丁,ACL,安全配置,网络和主机入侵检测等这些事情相关性比较大,约占不到30%的工作量。

    应用与交付安全:对各BG,事业部,业务线自研的产品进行应用层面的安全评估,代码审计,渗透测试,代码框架的安全功能,应用层的防火墙,应用层的入侵检测等,属于有点“繁琐”的工程,“撇不掉、理还乱”,大部分甲方团队都没有足够的人力去应付产品线交付的数量庞大的代码,没有能力去实践完整的SDL,这部分是当下比较有挑战的安全业务,整体比重30%+,还在持续增长中。

    业务安全:上面提到的(2),包括账号安全、交易风控、征信、反价格爬虫,反作弊反bot程序、反欺诈、反钓鱼、反垃圾信息、舆情监控(内容信息安全)、防游戏外挂、打击黑色产业链、安全情报等,是在“吃饱饭”之后“思淫欲”的进阶需求,在基础安全问题解决之后,越来越受到重视的领域。整体约占30%左右的工作量,有的甚至大过50%。这里也已经纷纷出现乙方的创业型公司试图解决这些痛点。

    对整体介绍的部分在前面的篇幅讲的比较多,主要目的是希望“视野”部分不缩水,这些概念在后面篇幅都不打算再展开了,如果你迟迟没看到技术篇,很正常,这只是一个开头而已。下一篇谈谈互联网企业安全管理和传统行业安全管理的区别。

    0x03 互联网企业安全管理和传统行业的区别


    总体来看,传统安全偏重管理,“三分技术,七分管理”,互联网行业偏重技术,我认为应该倒过来。其实这种说法也是不准确的,到底什么算技术,什么算管理,这些都没有明确的定义,安全领域大部分所谓管理不过是组织技术性的活动而已,充其量叫技术管理,如果你较真这些理论那你就掉坑里了。

    先说一下传统安全和互联网安全的建设需求上的差异:

    传统安全:

    IT资产相对固定 业务变更不频繁 网络边界比较固定 IDC规模不会很大甚至没有 使用基于传统的资产威胁脆弱性的风险管理方法论加上购买和部署商业安全产品(解决方案)通常可以搞定。 互联网安全生态,对于大型互联网而言,需要应对:

    海量IDC和海量数据 完全的分布式架构 应对业务的频繁发布和变更 同时架构层面关注:

    高性能 高可用性 扩展性 TCO(ROI) 在规模不大的互联网公司,传统的风险管理方法论是可以沿用的,但在大型互联网公司传统的方法论可能会失效,因为你可能连基础架构上跑什么业务都搞不清,你想理清所有的系统接口间的调用关系以及数据流去检视设计风险以及设置细粒度的访问控制就是件不现实的事情,产品线极多时业内没有任何一个团队敢说自己有能力支持全产品线,对于高速发展的业务,当你理清了你想要的说不定架构又发生变化了,只有对占公司整体营收比较主要的以及培育性质的战略级的核心业务才有必要去深入调研并随之update,其他的还是要依靠自动化手段。

    从安全建设上来看,传统安全建设:

    在边界部署硬件防火墙、IPS/IDS、WAF、商业扫描器,堡垒机、在服务器上安装防病毒软件,集成各种设备、终端的安全日志建设SOC,当然购买的安全硬件设备可能远不止这些。在管理手段上比较重视ISMS(信息安全管理体系)的建设,重视制度流程、重视审计、有些行业也必须“等保合规”。

    其实这里还有一个很大的区别就是,互联网有生产网络和办公网络的概念,即便最近Google声称取消内网也是针对办公网络而非生产网络,互联网行业的大部分安全建设都围绕生产网络,而办公网络的安全通常只占整体的较小比重。但是对于某些传统公司,他可能完全没有生产网络而只有办公网络,他的网络安全也就变成了办公网络的网络安全。但我推测随着社会互联网+进程的加速,很多传统的公司也会有自己的生产网络,最终都变成和互联网公司一样的形态。所以对于那些在给传统企业客户提供咨询和解决方案的乙方的同学,如果你们不学习互联网安全,也会被淘汰。

    互联网的生产网络的解决方案基本上都是以攻防为驱动的,怕被黑、怕拖库、怕被劫持就是安全建设的最直接的驱动力,互联网公司基本不太会考虑等保、合规这种形而上的需求,只从最实际的角度出发,这一点是比传统行业更务实的地方。最近也遇到一个例子,说要在服务器上装防病毒软件,一看就知道是传统行业来的思路,不是没有真正做过互联网企业安全就是没被业务线挑战过,在大型互联网,光是性能损耗、运维成本和软件成本这几条就能分分钟把这种需求干掉,更不用进入对于服务器防护这种更实际的话题了。很多标准说到底都是各厂商参与编写,博弈并达成妥协,有利于自己产品销售的代言白皮书,并不是完全站在建设性的角度的,作为乙方卖卖无脑客户赚点钱自然无可厚非,但在真正的甲方做企业安全生搬硬套是会受到质疑并逐渐失去影响力的。

    对于超过一定规模的大型互联网公司,其IT建设开始进入自己发明轮子的时代,安全解决方案开始局部或进入全部自研的时代,例如不会购买硬件防火墙,而是用服务器+Netfilter的方式自建,不会部署硬件IDS/IPS,而是用其他方式来解决这个问题。其实不难理解,规模小的时候买台硬件防火墙放在最前面,省事。但是规模大了我去买1000台硬防放在IDC机房?光¥就受不了啊。其次,基于CAP理论和Map-reduce衍生的一系列互联网架构,本质上都具有“无限”水平扩展能力,而传统的硬件盒子式的解决方案其设计大多源于对过去体系架构的理解,基本不具备扩展能力,完全不能适应大规模的互联网架构,总体上属于相对封闭的单点式防护。在这种情况下甲方安全团队自己动手去打造完全围绕自身业务的解决方案也就成了必然趋势。

    自研或对开源软件进行二次开发+无限水平扩展的软件架构+构建于普通中低端硬件之上(PC服务器甚至是白牌)+大数据机器学习的方式是目前大型互联网公司用来应对业务的持续性增长的主流安全解决方案。是否真的到了机器学习阶段这个有点难说,但是安全进入大数据时代则是很稀松平常的事了。

    对办公网络和雇员信息安全管理而言,互联网公司的文化比较open,一般不太会维持激进的安全政策,这点也是跟传统行业差别比较大的地方

    下一篇继续介绍不同规模企业下的安全管理

    微博 http://weibo.com/ayaz3ro 知乎主页 http://www.zhihu.com/people/zhao-yan-68/ 个人站点 http://www.ayazero.com

    展开全文
  • 其实做攻防和研发安全产品完全是两码事,存在巨大的鸿沟,如果拿做攻防的团队直接去做安全工具开发,恐怕挫折会比较多,即便有些研究员擅长做底层的东西,但对于高并发生产环境的服务器工具而言,还是有很大的门槛。...

    初期三件事

    • 事前的安全基线
    • 事中的监控能力
    • 事后的应急响应

    其实做攻防和研发安全产品完全是两码事,存在巨大的鸿沟,如果拿做攻防的团队直接去做安全工具开发,恐怕挫折会比较多,即便有些研究员擅长做底层的东西,但对于高并发生产环境的服务器工具而言,还是有很大的门槛。另一方面做攻防和做研发的思路也截然不同,此时其实是在交付产品而不是在树立安全机制,所以往往要分拆团队,另外招人

    如何推动安全策略

    公司层面

    推动安全策略必须是在组织中自上而下的,先跟高层达成一致,形成共同语言,对安全建设要付出的成本和收益形成基本认知,这个成本不只是安全团队的人力成本和所用的IDC资源,还包括安全建设的管理成本,流程可能会变长,发布链条会比过去更长,有些产品可能会停顿整改安全,安全特性的开发可能会占用正常的功能迭代周期。程序员可能会站起来说安全是束缚,这些都是需要跟各产品线老大达成一致的,他们要认同做安全这件事的价值,你也要尽可能的提供轻便的方法不影响业务的速度

    战术层面

    很多时候我认为甲方安全团队思路受限的地方在于:总是把安全放在研发和运维的对立面上,认为天生就是有冲突的。

    其实有些问题处理的好,真正让人感到你提的建议很专业,研发和运维人员不仅会接受,而且会认为自己掌握了更好的编码技能或者安全配置技能而产生正向的驱动力

    程序员鼓励师是一种实施层面的权宜之计,同时反映出安全行业比较缺少既懂技术且情商又高的人

    安全需要向业务妥协吗?

    安全建设的本质是以一定的成本追求最大的安全防护效果,有所妥协也不应该发生在工程师层面,而应该在 Leader 和安全负责人这个层面。如果安全工程师自己提的整改方案这个层面上,自己主动开始妥协了,那后面很多事情都没法做了

    跨时间轴场景做防御

    修不了漏洞时可以采用一些治标的补救性措施,比如对有漏洞的页面做访问控制,只允许有限的 src.ip 访问,比如在前端的 WAF、IPS 设备上加规则过滤对应的恶意请求,或者临时性的去掉一些权限,或者干脆关掉某些功能,但凡你想得到的通常总能找到临时规避方案,即便是有了补丁升级也不是立即完成的,在大型互联网生产网络里,全网打完一个补丁是需要不少时间的,有可能一个礼拜都弄不完,而且修复过程中要考虑服务可用性需要使用灰度和滚动升级的方法,比如修复前先把负载均衡上的流量切换到备用节点,然后对坐节点的服务器打补丁,打完再把流量切回去,然后对备用节点的服务器打补丁,打完补丁后把临时防御措施再回滚(有价值的保留,核心设备上不建议留太多臃肿的规则),然后把特征加入全流量和主机 IDS。回顾整个时间轴的防护措施依次是:临时性规避措施 一> push补丁/根治措施 一> 取消临时性措施 一> 添加常态性的特征检测措施 一> 检测到漏网之鱼 一> 继续上述过程,这个过程离最佳实践实际上还差了一个环节

    风险缓解的原则

    在以下三者之间做最大平衡:

    • 风险暴露程度
    • 研发运维变更成本
    • 用户体验的负面影响

    T-Shirt Size 理论

    业务影响力越高,时间人力成本越低,执行优先级越高
    业务影响力低,时间人力成本投入大,直接砍掉这个需求
    业务影响力和时间人力成本大致相同时,要降低风险水平,使时间人力成本下降的更快

    自己发明安全机制

    如果安全漏洞的修复是一类问题,也分几种情况。第一种归入安全编程能力不足导致的安全问题,这类问题不需要通过导入新机制解决,而是通过加强 SDL 的某些环节,加强培训教育去解决。第二种情况则是属于在相应的领域还没有成熟的安全解决方案或者现有的安全机制对抗强度太弱,则可以考虑自己去造轮子

    安全工程师如果要晋升为 Leader 很重要的一点就是对安全事件和安全漏洞的抽象能力,没有抽象就谈不上 PDCA ,就意味着更高的管理者对安全 KPI 在你手上能否改进不一定有信心。在纵深防御体系向中高阶段发展时,实际上会比较多的遇到是否要创新安全机制的问题,但这个场景大多数公司未必会遇到

    SERIDE 威胁建模

    安全标准

    • ITIL(BS15000/ISO20000),绝大多数互联网公司的运维流程都是以 ITIL 为骨架建立的,想在运维侧建立安全流程必须熟悉 ITIL
    • SDL,研发侧的安全管理
    • ISO27001,企业安全管理领域的基础性安全标准

    业务持续性管理

    业务持续性管理(BCM)的全生命周期方法论如下图所示

    image_1c61vetdo1oe8fv31gt84u21cu19.png-287.9kB

    德勤的 BCM 方法论实施路径图:

    image_1c62cis9s1i6qd0k3uqufvs2s1m.png-299.2kB

    德勤业务连续性计划和管理:http://www.davislogic.com/bcm.htm

    应急响应

    image_1c62d6t681gmlqchvim1qfuq2i23.png-430.9kB

    PDCERF(Preparation、Detection、Containment、Eradication、Recovery、Follow-up)模型

    马斯洛需求

    image_1c62dponld7bak7fkh15001rt32g.png-352.2kB

    展开全文
  • 为什么需要企业安全框架一方面,实现业务与技术之间的“沟通”,让相关的业务与安全方面的技术对应起来另一方面,实现模块化管理,让负责某一模块的人员有相关的话题可以谈,同时对于应急响应也可以及时的排查等。...

    为什么需要企业安全框架

    一方面,实现业务与技术之间的“沟通”,让相关的业务与安全方面的技术对应起来

    另一方面,实现模块化管理,让负责某一模块的人员有相关的话题可以谈,同时对于应急响应也可以及时的排查等。

    企业架构开发模型


    企业安全控制模型

    CobiT模型,国际审计协会(ISACA)及治理协会ITGI联合制定目标集。

    企业架构是组织的,系统架构是计算机组建的

    计划和组织、获得与实现、交付与支持、监控与评价

    公司治理模型

    COSO模型,反欺诈财务相关发起的委员会。

    控制环境、风险评估、控制活动、信息和通讯、监控

    COSO是企业治理模型,CobiT是IT治理模型。

    过程管理模型

    ITIL模型,IT服务管理的最佳实践实施标准。

    CMMI模型,能力成熟度模型集成。

    紊乱、可重复、文档化、可监控、自动化




    参考:林很相关视频

    展开全文
  • 下一篇:企业安全隐私合规体系建设经验总结(二) 引子 在去年前三季度(2019年),我有幸主导了公司的安全隐私合规体系建设。几乎是从零开始,完成了ISO 27001、ISO 27017、ISO 27018、GDPR、等级保护三级、CCPA等...
  • 企业安全风险的来源有哪些?

    千次阅读 2015-01-16 15:50:37
    企业安全风险是对达到技术性能成本,和精度方面的目的,和目标的不确定性的一种度量,企业安全风险等级使用安全事件和安全事件出现的频率来分类的,企业风险源包括以下几个方面: 技术方面 可行性可操作性,...
  • 上一篇:企业安全隐私合规体系建设经验总结(四) 引子 在去年前三季度(2019年),我有幸主导了公司的安全隐私合规体系建设。几乎是从零开始,完成了ISO 27001、ISO 27017、ISO 27018、GDPR、等级保护三级、CCPA等...
  • 本课程中涉及10个方面的企业安全建设问题,分别是自建准入系统、企业数据防泄露系统建设、开源SIEM系统、Web应用防护、Web业务安全、Web漏洞检测、主机入侵检测、网络入侵检测、基础网络设置安全防护、威胁情报落地...
  • http://www.k59k.cn/
  • 从Google白皮书看企业安全最佳实践

    千次阅读 2017-04-07 15:33:00
    前不久Google发布了一份安全方面的白皮书Google Infrastructure Security Design Overview,直译的版本可以参考“网路冷眼”这版《Google基础设施安全设计概述》,直译+点评的版本可以参考“职业欠钱”的《Google...
  • 上一篇:企业安全隐私合规体系建设经验总结(一) 下一篇:企业安全隐私合规体系建设经验总结(三) 引子 在去年前三季度(2019年),我有幸主导了公司的安全隐私合规体系建设。几乎是从零开始,完成了ISO 27001、...
  • 置身全球化进程的今天,国内企业如何规避后疫情时期带来的不利影响,依然是个难题。 对创业公司来说,确保充足现金流成为度过难关的首要条件。头部创业公司估值暴跌,融资受挫哀声连连;而中下游创业公司,或将...
  • 奇安信 (原360企业安全)实习生面经

    千次阅读 2019-05-08 16:56:32
    岗位: 网络工程师(安全方向) 笔试:赛码平台 涉及内容 网络原理,数据结构,linux,最后两个编程 一面(视频面): 面试官在机房忙,简单问了一下,时间没超过十分钟。 第一个问题,问了一下你认为的运维是...
  • 每一个企业级的人 都置顶了 中国软件网中国软件网 为你带来最新鲜的行业干货小编点评我们希望邀请更多的生态伙伴共同探讨共同行动2018年4与人25日北京站,不见不散!趋势洞察生态视角开放、合作、共享、共赢,用友...
  • 360企业安全服务端面试要求

    千次阅读 2018-09-13 22:40:02
    360企业安全服务端面试要求 职位描述:你想了解大数据安全产品的相关知识?你想学习一个系统服务的所有知识?你想变成服务端开发的无敌全能手?来360企业安全,在这里大展身手! 任职要求:1、计算机相关专业大学...
  • 随着计算机网络的不断发展,全球信息化已成为人类发展的大趋势,网络信息化的飞速发展同样给企业带来了巨大的网络安全隐患---病毒、黑客、垃圾邮件、木马程序等等。为了规避风险企业纷纷上马各类安全产品用以保证...
  • 几乎所有企业对于网络安全的重视程度一下子提高了,纷纷采购防火墙等设备希望堵住来自Internet的不安全因素。然而,Intranet内部的攻击和入侵却依然猖狂。事实证明,公司内部的不安全因素远比外部的危害更恐怖。 ...
  • utm_medium=referral一、背景Facebook数据泄露事件一度成为互联网行业的焦点,几百亿美元市值瞬间蒸发,这个代价足以在地球上养活一支绝对庞大的安全团队,甚至可以直接收购几家规模比较大的安全公司了。虽然媒体上....
  • 大话企业IT安全解决方案

    千次阅读 2017-06-02 13:54:03
    安全是个技术+管理(人、流程)的问题。 技术解决的层次1. 基础安全服务 (认证、授权、审计) 2. 基础设施层(IPS, WAF) 3. 软件层 3.1 OS 3.2 应用APP (协议、漏洞) 4.安全服务(服务开发、管理、运营) ...
  • 2018年,企业网络安全方面将会呈现出如下态势

空空如也

1 2 3 4 5 ... 20
收藏数 554,611
精华内容 221,844
关键字:

企业安全