IT安全，你准备好了吗？

securitypluscn

回复 101# to407

".....在大公司，有一点很重要，就是严格的流程和快速响应。 <<<<   这两点有点冲突。
     
     平时我们做一些操作，都要遵循流程，都有要日志log，有audit。 这都是安全的要求， 但是出了事之后的响应不是这样子的， 快速响应要求的是不把问题扩散，不让损失蔓延，需要立即采取措施，做隔离 甚至无奈的时候 拔插头。....  "

严格的流程和快速响应并不冲突！对突发事件的成功处理需要周密的应急计划(contingency plan)作保证。而应急计划中最重要的组成部分就是突发事件处理流程。 你说的“立即采取措施，做隔离 甚至无奈的时候 拔插头”实际上就可能是突发事件处理方案流程的一种。


   

to407

回复 106# securitypluscn


    怎么会不冲突。。。

    平时做变更 需要邮件，报告来要求权限等级 要求经理的批准。  出问题的时候， 需要的是一线人员果断的决定。  

   
    变更是有计划 有流程的。   出问题 更多的是突然的，没有照本宣科的。

  
     就举一个简单的例子， 当发现系统内存 快速地消耗，基本上每小时都线性地 leak。 这时候怎么办，重启系统，下线应用，还能做别的？

securitypluscn

回复 107# to407

"
你“平时做变更 需要邮件，报告来要求权限等级 要求经理的批准。” 走的流程和突发事件处理预案中的流程是不同的。对突发事件的处理方法和具体步骤也应该是有计划有准备的。

"。。。。就举一个简单的例子， 当发现系统内存 快速地消耗，基本上每小时都线性地 leak。 这时候怎么办，重启系统，下线应用，还能做别的？。。。。"

这个问题问的好，你如果有突发事件处理预案，就知道该怎么做了。
给你个链接，你先看看
http://doc.mbalib.com/view/23f258d806def155fda549c00b5e803c.html



   

to407

回复 109# securitypluscn


    这种预案没有任何的可操作性。

    讲的是 多层级的负责制， 在IT业务上 是有大问题的。 IT业务的紧急响应 应该是更加扁平化的结构。

   
还是前面提到的案例

1) .  系统垮掉，需要 failover到备库。  这个决定谁能做？如果是层级负责制， 那么一线的工程师是不敢做决定的，一旦他们切换失败，将负所有责任，上级会推得一干二净。于是就是几个层级间的扯皮，  这样 failover 就没有意义了。


2).   新上一个业务， 导致服务器的内存有泄漏。  一线有没有权利做决定？  他需要同产品经理去吵架， 如果他擅自下线产品，强势的产品经理会认为在系统没有垮掉的情况下，这么做损害他的利益。    当然对于一线工程师， 最保险的办法， 等着服务器垮掉，这样就有理由有证据说明是这个产品导致的。 大家不得罪，但这对于公司来讲就是大损失。


有的时候 不做一线的人 想法很天真， 以为平时权限归领导， 打仗了就把枪往一线工程师手上一扔， 就是最佳实践了。

这样的安全策略 经不起考验。

比较可行的办法是妥协， 不要一味喊安全的口号， 平时多给一线 权限，扁平化，  加强audit 和log。  才能有效地减少重大问题的发生。  多层级的架构容易 导致推诿责任，不敢负责，小问题积成大问题。

airfy

to407 发表于 2015-01-27 10:43
回复 109# securitypluscn

看到两位讨论这个问题，有点意思，就进来插一腿。我个人觉得，应急预案肯定是需要的，但不应该是那种出了事层层上报，然后等待... ，应急预案本身就应该包含每个人应该做什么，而不是去等待领导指示。为了防止推诿扯皮的现象，应该把职与责分开。

airfy

dengbao2001 发表于 2015-01-16 13:56
360也算后起之秀了

不要太在意这个公司的老板之前做过什么事情，重要的是现在他在做什么，而且他现在 ...

看到这句话，深有感触。人性是一个很难琢磨的东西，浪子回头毕竟是少数。我通过3721开始知道了某老板，到了360年代，也帮别人处理过某些问题，虽然次数不多，但我总结出来一条：严格来讲，浪子回头不适用于某老板

只是借用一下贵地发个感叹，别介意  -

airfy

MS今天是最后一天了，还来得及。我有收藏书的癖好

1、在贵公司IT建设中，网络安全方面主要采用哪些措施，效果如何？
从题目来看，似乎只是讨论网络安全方面的措施，说来说去不外乎就是一些常见的，例如防火墙、入侵检测、ACL、各种代理、各种过滤等等，这些都没啥好讨论的。我觉得最重要的不是这些具体的技术细节，而是IT策略和对应的基础架构。这就象盖房子一样，地基做好了，后面的事情就很轻松了。举个例子，如果公司的IT的政策是所有的硬件、信息、数据属于公司的资产；遵守权限最小化原则；公司范围内的IT资源都是可信的，外面的都是不可信的。OK，根据这个政策采取对应的基础架构，采用对应的防护措施，例如，公司的IT设施全面受IT控制，公司网内无需特别的ACL，任何的数据在进入公司之前必须扫描过滤。。。 一套好的IT策略、好的基础架构当然会带来好的效果。
如果扩展到信息安全的范筹来讲，则建立一套合适的信息安全管理体系是非常重要的。世上没有绝对安全的IT系统，但是一套合适的安全管理体系可以把风险控制在适当的、可接受的水平。

2、你认为要成为安全方面的专业人员，要具备什么方面的知识？
要想成为安全方面的专家的话，要掌握的东西就很多了，从软件方面的数据结构、算法、软件工程，到网络方面的TCP/IP协议、IP路由与交换、无线网络，再到通信原理、密码学，再到信息安全管理体系、风险管理理论，等等好多东西要学习，难度很大。

3、你曾经在IT安全方面是如何学习的，或有什么计划要如何加强自己安全方面的知识？
在掌握了计算机专业知识后，再从CISSP和ISO27000入手会比较合适。

securitypluscn

回复 110# to407

“这种预案没有任何的可操作性。”
能否提供一些可操作性的预案让我们参考一下下

“ 。。。系统垮掉，需要 failover到备库 ，这个决定谁能做？。。。”
这个问题问的好！ 答案在应急预案中白纸黑字的写着呢？“项目责任人应立即核查突发事件的影响程度和范围，检查有关备用设备的运行状况。如备用设备可用，将系统切换至备用设备。”

“...那么一线的工程师是不敢做决定的...”
这就对了，恭喜你已经掌握了信息安全管理的本质。每一个信息安全决策都是商业决策而不是技术决策！一线工程师在没有正式授权的情况下是不应该自己做决定的。这种授权可以来自两方面，上级领导或是公司相关文件。这些文件包括政策，标准，流程等等。。这就是为什么工程师在面对安全突发事件时要依据流程处理。走流程实际在客观上也是工程师对自己的保护，防止互相推卸责任。






   

securitypluscn

回复 111# airfy

欢迎插腿！

预案经过反复测试和演练后，实际操作起来会很快。应为它本身就是为了对突发事件能够进行快速反应而设计的。

预案并不是“出了事层层上报，然后等待... “。预案中写的很清楚： “发生网络与信息系统突发事件后，突发事件涉及的应用部门应先进行必要处置” 。应急预案本身已经包含了每个相关责任人应该做什么。




   

airfy

securitypluscn 发表于 2015-01-27 15:00
回复 111# airfy

欢迎插腿！

没仔细看，基本上同意你的意见。但是在实际运用中又不能过于教条主义，这时候职责分离的原则就显出好处来了，下面的人尽管放手去做，出了问题领导来承担责任。这需要有好的领导，也要有好的下属，哈哈。