- 论坛徽章:
- 0
|
国内网络安全风险评估市场与技术操作（转）
3. BS7799和OCTAVE
3.1 BS7799的优势和弱点
要初步了解BS7799，我觉得从两个角度入手
了解BS7799的安全管理流程，也就是建立信息安全管理体系的方法和步骤
系统了解BS7799中提到的10类127个控制项的内容
并且能够在此基础上针对不同行业选择(甚至新增)控制项。就如最近移动集团提出的NISS(网络与信息安全标准)一样。
个人感觉BS7799的最大缺陷就在于可操作性不强，如果仅仅按BS7799的要求操作(类似ISO9000的评审)，有可能最终达不到初始的安全目标。这或许也是BS7799和ISO17799呼声很高，但实际应用或者通过评审的企业并不多的原因之一。作为参考，这里给出一份sans提供的BS7799检查列表。
3.2 OCTAVE的有效补充
所谓OCTAVE，实际上是Operationally Critical Threat, Asset, and Vulnerability Evaluation的缩写，指的是可操作的关键威胁、资产和弱点评估。在我的理解中，OCTAVE首先强调的是O，其次是C，也就是说，它最注重可操作性，其次对关键性很关注，把握80/20原则 
简单描述我理解OCTAVE的几个重点(实际上在OCTAVE中的每个环节都是不可忽视的，这里所说的几个重点是我认为OCTAVE较好、或者评估过程中比较关键的部份环节)：
过程控制(整体)
OCTAVE将整体网络安全风险评估过程分为三个阶段九个环节，分别是：
阶段一：建立基于资产的威胁配置文件
01. 标识高层管理知识
02. 标识业务区域知识
03. 标识一般员工知识
04. 建立威胁配置文件
阶段二：标识基础结构的弱点
05. 标识关键资产
06. 评估选定的资产
阶段三：确定安全策略和计划
07. 执行风险分析
8A. 开发保护策略A
8B. 开发保护策略B
下图是CERT在为一家医院进行风险评估时的进程时间表，我们可以作为参考。
创建威胁统计(process 4)
这个过程实际上完成两件事，一是对前面三个过程中收集的数据进行整理，使数据分析清晰。二是能够通过分析资产的威胁，创建重要资产及资产面临威胁的全局视图。
从下图我们可以看到，OCTAVE对某一资产的资产、访问、动机、参与者和结果都进行了分析(该图仅是针对一项资产──个人计算机，和一种访问──网络而建立的威胁视图)，这种方式的确有助于我们看清企业内部的威胁情况。
识别关键资产(process 5)
也是第一阶段的延续，按OCTAVE的说法，分成两步：标识组件的关键种类和标识要分析的基础结构组件。如果从操作灵活性考虑，我们也可以在阶段一的时候为资产和知识标识出CIA(机密性、完整性和可用性)，通过对CIA的综合运算得出最终结论。
进行风险分析(process 7)
与创建威胁统计中的威胁视图相对应，在这里需要标识出威胁可能造成的影响。要注意到的是，风险分析并非仅象下图那样是单一的，而是多种系统之间可能交叉影响，因此这个视图最终完成后将会是很大的一张图表。
4. 中小企业的特点和对OCTAVE的重新评价
4.1 中小型企业和大型企业在评估活动中的异同点
最直接的想法，大型企业和中小型企业对安全的关注要点是否完全相同？又是否完全不同？哪些在大型企业中做过的事是可复用的？我很少看到关于这些方面的讨论，因此也想在这里将问题提出，并给出我的粗浅考虑，希望能够引玉。
相同点(可以复用的部份)
1. 资产评估
资产调查表格
资产属性和赋值调研表格与方法
关键资产的调查方法
2. 威胁评估(部份中小企业甚至可以不用进行)
BS7799评审表
OCTAVE威胁分析方法和视图
事件分析方法
3. 弱点评估
远程扫描方法和工具
人工审计方法和工具
渗透测试方法和工具
4. 风险分析
现有风险视图提炼方法和报告
不同点(需要单独开发调研的部份)
1. 资产评估
资产报告(不同行业、规模的企业，关键资产有很大区别)
2. 威胁评估
面临的威胁面比小企业更广
3. 弱点评估
风险规避措施
4. 风险分析
针对组织特点的解决方案
管理制度和策略框架
4.2 重新评价OCTAVE
通过对OCTAVE的初步学习，我们可以认识到它具有许多BS7799的所缺乏的可操作性方面的特点，但离完美还有一定距离，简单谈几点不足：
过份强调对大企业的评估活动，评估流程比较繁琐，完整视图建立不易操作，要求组织中多人参与。
风险控制行动列表粒度较粗，与企业后续安全建设的实际工作有一定距离。
由于强调了操作，执行时所依据的标准就相对简单(可能有主观臆断的因素在内)。
任何事物，就算非常优秀，也都不能全盘照搬，是需要批判接受的，从上面对BS7799和OCTAVE的简单分析，你是否能够提炼出你自己的评估方法？
5. 如何制订最适合您企业的风险评估计划
这里考虑采用一个小企业的评估实例来说明制订适合自身当前状态的企业风险评估的方法。由于暂时没有适合的案例提供，因此留待下一版本完善。
6. 实施过程简述
6.1 定义阶段
实际上是售前工作的延续，即明确项目范围，清晰界定用户的需求。这点看似简单，但实际操作者却需要相当有经验，能够判断自己所拥有的资源;能够在既定时间内完成多少工作;能够与客户有技巧地谈判将其需求控制在最恰当的水平并维持到项目结束。
我们在这里列出了五个模块：前期交流、初步方案、投标方案、答标文档和参考报价。
按照实际项目操作流程，在售前阶段这五个模块的工作应该完整进行一遍。进入项目定义阶段时，实际上用户已经对网络安全风险评估有了一定了解，并且比较清楚自己的网络环境需要评估到什么程度，因此本阶段用户会就投标方案要求厂商进行进一步描述，并且就他们感兴趣的细节进行展开。
6.2 蓝图阶段
双方拟定项目的详细进度计划，建议在计划过程中至少要包含下面几部份内容：问题描述、目标和范围、SWOT分析、工作分解、里程碑和进度计划、双方资源需求、变更控制方法。
在蓝图阶段中需要召开蓝图会议，在会议结束后，必须在双方认可的基础上制订并签署项目蓝图，后续一切工作严格按蓝图进行。
评估项目对客户的知识水平要求较高，通常在项目前期需要就评估方法进行培训，建议在蓝图阶段完成项目的培训工作。
另外需要提醒的是，由于多数企业的资产并没有很好地理顺，因此资产评估的前期协调工作如果能够尽早开始，可以有效地保证项目的时间。
6.3 执行阶段
这是最关键的阶段，绝大多数操作都在这一阶段完成，我们可以再将这一阶段细分为四个环节，分别如下：
资产评估(可以远程完成)
系统和业务信息收集
资产列表
资产分类与赋值
资产报告
资产评估的内容并不复杂，在这部份工作中，重点在于与客户共同进行资产的分类与赋值。同时需要注意控制资产评估的完成时间，因为明确资产后才能有效进行后续的威胁与弱点评估，否则容易导致事倍功半。
威胁评估(本地完成)
IDS部署搜集威胁源
收集并评估策略文档
BS7799顾问访谈
事件分析
威胁报告
威胁评估中访谈占了现场工作的最大部份。但由于现阶段业界对于威胁的界定存在多种标准，因此可以说威胁评估是较难操作的一部份。建议在实施前先参考威胁评估报告样例。
如果能够通过访谈获取到较为完整的安全事件信息，则可以考虑将不进行威胁评估，以更能够清晰分析本质的事件分析代替。
弱点评估(本地完成)
远程扫描
人工审计
渗透测试
弱点报告
弱点评估属于纯技术操作，这里不加详述。
风险分析和控制(可以远程完成)
数据整理、入库及分析
安全现状报告
安全解决方案
当现场工作结束，基础数据收集完毕后，如何对浩如烟海的信息进行提炼和挖掘，其中也有很多技巧。最终的风险分析需要看得清晰透彻，而且方案的表现形式要比较切合客户需求。解决方案就三个字：可操作。
6.4 报告阶段
在项目报告阶段，所有的现场工作和大部份文档工作已经完成，这时的关键任务是：让用户真正理解并且认可我们的工作成绩。因此这阶段建议需要与用户进行深入细致的沟通(需要面对面交流，以达到最佳效果)。
报告阶段需要注意各种细节调整(有些需要结合项目特点进行考虑)，例如：
1.在报告的最前面增加“文档导读”章节;
2.将客户方配合工作人员也写入报告作者;
3.给领导提供一份简洁有力的总结;
4.等等……
6.5 售后服务
按照Octave评估方法的观点，用户在完成一次安全评估之后，相当于获取了其当前风险的快照(Snapshot)，同时也就完成了对其信息安全风险基线的设置。之后，组织必须解决或管理评估过程中标识的优先级最高的风险，并按照开发的解决方案进行风险的控制和消除。
但由于组织的安全状态会随着时间而发生变化，所以必须通过执行另外一次评估定期地为用户重设基线。所以在这里我们可以按照PDCA循环(Plan、Do、Check、Action)来定义一次评估后的工作。
7. 评估中的项目管理
7.1 确定项目管理小组
明确项目的组织结构
通常三人以下小项目以非正式结构存在即可。但有相当耗费资源的大型评估项目时，则需要恰当考虑并论证是否采用矩阵结构对项目资源进行合理利用。
明确包含的部门和关键人员
通常项目组中会包含商务、评估组、研究部等跨部门的成员，需要提前确定并且明确管理权限和项目成员的工作重心，这可以有效减少后期项目中的障碍。
明确项目管理职责选择项目经理、项目监理(至少是文档监理)、子项目经理等岗位人选。如果资源充足，尽量不要资源复用，否则最终可能成为资源瓶颈。
7.2 调度与资源分配
优化项目流程
类似统筹，将项目中的所有任务全盘考虑时，可以发现有部份任务可以并行、有部份任务可以提前、有部份任务并不需要很多前置任务……由专人对项目流程进行优化，估测任务的执行时间段。
明确项目重点并确定资源优先次序
确定关键路径和里程碑
7.3 跟踪、报告和控制
定义数据需求
数据搜集过程中需要对数据进行明确的定义(甚至采用标准工具进行)，这可以保证不同人获取的数据格式、数据描述和测量尺度是一致的。
数据分析和文档生成
交付进度表
7.4 常见陷阱
7.4.1 授权模糊
经常项目中的项目经理、项目监理、子项目经理、咨询顾问、技术工程师等往往一人兼任多职，如：项目监理同时兼任几个节点的子项目经理。一人多角的最直接后果就是导致每个角色都没有充当好。
7.4.2 需求膨涨
在评估前期，用户对安全乃至评估本身可能缺乏了解，但随着评估的深入，他们逐渐会成为安全领域的“通才”，这时候会提出大量的新需求，对这些新需求的有效控制和引导(成为新项目的引子)相当重要。
7.4.3 资源错位
这主要在资源不足的情况下容易发生，举例来说：我们预定由Unix专家A和网络设备专家B共同完成对甲地系统的弱点评估，但在资源不足的情况下，则有可能B正在乙地评估无法抽身，必须由A独立完成所有操作。
7.4.4 沟通不足
多数技术型员工技术操作能力很强，但在项目中的沟通相对缺乏。在一次评估项目的收尾阶段，就有用户委婉地指出：你们可真算是“埋头苦干”了！
8 参考资料
清华大学出版社 《信息安全管理》
机械工业出版社 《信息安全管理概论》
通过网络获取的各家公司的资料
--------------------------------------------------------------------------------
Power by Debian, Created with Vim |
|
免费注册
发表于 2004-06-16 11:37
