ISO 27001 资讯安全管理系统 【解析】(十一)

了解组织与第三方的关系对於确保业务及其所拥有资讯的安全性非常重要,尤其是在第三方活动可能使资讯安全受到威胁的情况下(即使其活动与资讯显然无关,例如清洁工)。与任何第三方合作时,对於资讯安全来说,定义以下内容非常重要:

  1. 法律责任、问责制和保险:必须详细了解所有各方的责任,从风险评估流程了解需要确定问责制的领域,灾害回复规划和资安事件回应也是验证所有权和保险责任是否落在正确范围的方式。
  2. 存取和授权:必须确认存取及进出管制政策,如果组织允许承包商进入建筑物,应该了解谁拥有钥匙或门禁卡、谁确保员工接受培训及资讯安全,还应考虑存取IT系统和资讯的能力。
  3. 揭露和隐私:组织应定义和分类正在使用和共享的资讯,并指定适用的规则和法规。
  4. 合约条款:应明确规定与第三方的合约条款,以确保所有各方都明确对所开展工作的期望,并制定违约时的处罚或责任。
    前面谈了这麽多,就现况而言,在国内想要导入及验证的组织,很少是先做好第四章分析的工作後再来决定范围,实务上到底要如何做比较适当呢?因为资通安全管理法的颁布施行,所以区分两种不同的方式来说明:

(一) 适用资通安全管理法的组织
现在很多组织为了资通安全管理法的缘故需要导入ISMS,但是许多承办人员因为对法令不熟悉,产生了很多疑问;虽然主管机关已经执行过很多场的教育训练,也制作了许多范本供大家参考,但是很多人仍有许多不清楚的地方。可以依照下列步骤来决定范围:

  1. 核心业务
    依照资通安全管理法施行细则第七条,先找出组织的核心业务,通常可以从组织法规中找到,例如:内政部组织法第 11 条户政司掌理下列事项:六、关於户籍登记事项,由此可以知道内政部户政司核心业务为户籍登记事项。
  2. 核心系统
    支持核心业务运作必要之系统。组织可从核心业务中找到所需要的核心系统。通常对於核心系统的判定会有一些困难,有些核心业务并不一定依存於资讯系统上,当系统不能使用时,可能有很多方式可以替代,这样到底算不算是核心系统呢?在资通安全管理法施行细则第七条(节录):「前条第一项第六款所称核心资通系统,指支持核心业务持续运作必要之系统,或依资通安全责任等级分级办法附表九资通系统防护需求分级原则之规定,判定其防护需求等级为高者。」所以,核心系统有两个判定方式,一个是支持核心业务持续运作必要之系统,另一个是防护需求等级为高者,举例来说:紧急救护的机关设置了一个网路求助系统(网站、APP),如果这个系统失效,这个机关可以运用其他方式达到紧急救护的业务目标(电话、EMAIL、简讯等),所以这个网路求助系统到底算不算是核心系统?从核心业务上来看它可能只是一个辅助系统,但从资通系统防护需求来看(机密性、完整性、可用性、法律遵循性),等级应该可判定为高,所以网路求助系统仍视为核心系统。另外,关键基础设施提供者的关键基础设施,必须参考主管机关的规定来判定。当然囿於人力及技能的关系,刚开始所有机关的资通安全维护计画未臻完善,常常在核心业务及系统上有判定上的问题,而主管机关也没有多余的人力能够矫正这些问题。随着时间的推移,这样的情况应该可以得到一些改善。然而,实务上常见到核心系统非由资讯单位负责维运的情况,而资讯单位及业务单位的责任归属不明确,导致应负的责任无人承担,例如:本人曾经稽核一个组织,其核心系统对於帐号管控不佳,承办单位认为他们完全不了解资讯技术,这个问题应该由资讯单位解决;而资讯单位认为系统是由承办单位委外维运,跟资讯单位无关。如此对於资讯安全管控上完全没有帮助,也枉费了订定资通安全管理法的原意。

<<:  连续和非连续内存分配之间的区别

>>:  Kubernetes 架构

[Day18] Null byte Injection

前言 %00 正文 概念 Null byte Injection是一种将Null Byte(如%00...

就做自己吧,其他角色都有人了。

就做自己吧,其他角色都有人了。 Be yourself; everyone else is alre...

#30 No-code 之旅 — 恭喜完赛!

最後一天!礼拜五快乐!恭喜大家完赛!恭喜自己XD 今天来回头看看我们这三十天学了哪些事,还有讲一下未...

第11天 - PHP修改MySQL资料表内容

今天来做从网页修改MySQL资料表内容(修改会员的名称) 首先要做出一个修改按钮(虽然说是按钮,但我...

Day14 逻辑斯回归实作

https://github.com/PacktPublishing/Machine-Learni...