Wiki源代码15 信息安全管理实践
Version 21.1 by superadmin on 2021/12/29, 17:16
Show last authors
author | version | line-number | content |
---|---|---|---|
1 | **申明:** | ||
2 | |||
3 | 本系列ITIL 4实践中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译, | ||
4 | 国内众多从事ITIL理论推广及落地实践的专家们参与,需要下载最新翻译版本请关注微信 | ||
5 | 公众号:ITILXF,也可访问ITIL4中文知识库网站:itil4hub.cn。 | ||
6 | |||
7 | |||
8 | 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 | ||
9 | |||
10 | |||
11 | 本文档翻译工作参与人员: | ||
12 | |||
13 | 翻译:隗玉凯 | ||
14 | |||
15 | 审校:史坦晶 | ||
16 | |||
17 | |||
18 | 总审: 长河 | ||
19 | |||
20 | 审核: 魏钧军 | ||
21 | |||
22 | 统筹: 常宏 | ||
23 | |||
24 | |||
25 | |||
26 | ---- | ||
27 | |||
28 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
29 | {{toc/}} | ||
30 | {{/box}} | ||
31 | |||
32 | = **1 关于本文件** = | ||
33 | |||
34 | 本文档提供了信息安全管理的实践指南,它分为五个主要部分,内容包括: | ||
35 | |||
36 | * 有关实践的概述 | ||
37 | * 实践的流程和活动以及它们在服务价值链中的作用 | ||
38 | * 实践中涉及的组织和人员 | ||
39 | * 支持实践的信息和技术 | ||
40 | * 实践中关于合作伙伴和供应商的注意事项。 | ||
41 | |||
42 | == **1.1ITIL^^®^^4认证方案 ** == | ||
43 | |||
44 | 本文档的选定内容可作为以下课程的一部分进行测试: | ||
45 | |||
46 | * **ITIL专家(高速IT)** | ||
47 | |||
48 | 有关详细信息,请参阅相应的教学大纲文档。 | ||
49 | |||
50 | |||
51 | |||
52 | ---- | ||
53 | |||
54 | = **2 概述** = | ||
55 | |||
56 | |||
57 | == **2.1** **目的和描述** == | ||
58 | |||
59 | 信息安全成为一项越来越重要又困难的任务。信息安全管理实践在数字化转型的背景下越来越重要。这是由于跨行业数字化服务的增长,在这种情况下安全信息泄露可能会对组织的业务产生重大影响。云解决方案的更广泛使用,以及合作伙伴和服务消费者的数字化服务更广泛集成产生了新的关键依赖关系,而控制信息如何被收集,存储,共享和使用的能力却有限。合作伙伴和服务使用者的处境相同,通常会在数据保护和信息安全解决方案上进行投入。但是,组织之间完整性和一致性的缺失产生了新的漏洞,需要了解和处理。信息安全管理实践与其他实践(包括:可用性管理,容量和性能管理,信息安全管理,风险管理,服务设计,关系管理,架构管理,供应商管理和其他规范)结合在一起,可确保组织的产品和服务满足所有相关方要求的信息安全级别。 | ||
60 | |||
61 | 许多组织认为信息安全管理实践是广义安全管理的特定分支。在服务经济中,每个组织的业务都是由服务驱动和数字化赋能的。这会带来策略更紧密的整合,因为,安全管理更关注数字化服务和信息的安全。在数字化转型消除了IT管理和业务管理边界的情形下,这种整合变为可能并发挥作用。(有关此主题的更多信息,请参见ITIL®4:高速IT)。 | ||
62 | |||
63 | |||
64 | == **2.2 术语和概念** == | ||
65 | |||
66 | |||
67 | === 2.2.1 安全特性 === | ||
68 | |||
69 | 信息安全管理实践有助于确保开展业务所需信息的保密性,完整性和可用性,同时需要一些活动和控制来保持这些特性。此外,信息安全管理实践通常涉及身份验证和不可抵赖。 | ||
70 | |||
71 | |||
72 | **定义:保密性** | ||
73 | |||
74 | 防止信息泄露给未授权实体或对未授权实体可用。 | ||
75 | |||
76 | |||
77 | 保密性是许多人在考虑信息安全时想到的第一件事。个人和组织希望确保秘密保持隐密,并且其个人信息或业务信息不被滥用。 | ||
78 | |||
79 | |||
80 | **定义:可用性** | ||
81 | |||
82 | 确保信息可以在需要时被使用的特性。 | ||
83 | |||
84 | |||
85 | 如果该信息在需要的时间和地点不可用,则组织无法开展其业务。 | ||
86 | |||
87 | 可用性管理实践考虑了服务可用性的许多方面。然而,信息安全管理实践更关注信息的可用性。 | ||
88 | |||
89 | |||
90 | **定义:完整性** | ||
91 | |||
92 | 确保信息准确无误,并且只能由被授权人员和活动进行修改。 | ||
93 | |||
94 | |||
95 | 不正确的信息可能比根本没有任何信息更糟糕。例如,如果一家银行错误地认为客户的帐户中有大量资金并允许他们提取该笔款项,则该银行可能遭受重大损失。 | ||
96 | |||
97 | 身份验证用于建立人与物的身份 | ||
98 | |||
99 | |||
100 | **定义:身份验证** | ||
101 | |||
102 | 验证看起来或声称是真实的特性或属性确实是真实的。 | ||
103 | |||
104 | |||
105 | 用户名和密码通常用于对人员进行身份验证,尽管通常优先推荐使用生物特征识别和安全令牌这些更严格的身份验证方式。 | ||
106 | |||
107 | * 网站可以使用证书和加密来提供身份验证 | ||
108 | |||
109 | **定义:不可抵赖** | ||
110 | |||
111 | 提供不可否认的证据,证明非法事态发生,或者非法行为正在进行,并且此事态或行为由特定实体执行。 | ||
112 | |||
113 | |||
114 | 在IT系统和服务存在之前,就已经在商业交易中使用了不可抵赖技术。传统上使用签名,如果需要更高级别的证明,则可能需要对该签名进行公证。信息安全依赖不可抵赖性,因此交易可以进行。这对于保护信息完整性是必不可少的。 | ||
115 | |||
116 | |||
117 | === 2.2.2 资产,威胁,威胁制造者和漏洞 === | ||
118 | |||
119 | |**定义:资产** | ||
120 | |资产是对组织具有价值的任何事物。 | ||
121 | |||
122 | 资产可能包资产可能包括硬件,软件,网络,信息,人员,业务流程,服务,组织,建筑物或其他对组织有价值的东西。信息安全管理实践帮助组织保护资产,以便其开展业务。 | ||
123 | |||
124 | |||
125 | === 2.2.3 风险管理术语 === | ||
126 | |||
127 | 信息安全管理实践使用了许多风险管理的术语和概念。这些术语在风险管理实践中也进行了描述。 | ||
128 | |||
129 | 风险管理术语和定义见表2.1。 | ||
130 | |||
131 | 表2.1 风险管理术语 | ||
132 | |||
133 | [[image:1639730208796-535.png]] | ||
134 | |||
135 | |||
136 | |||
137 | == **2.3 范围** == | ||
138 | |||
139 | 如第2.1节所述,信息安全管理实践的目的是“保护组织开展业务所需要的信息”。该信息可以在信息系统上存储和处理,但是同样可以将其记录在纸上,或通过语言传递。本实践与此类信息的保密性,完整性和可用性有关,而不论在何处以及如何存储和处理这些信息。尽管重点是信息,该实践同时也与服务管理全部四个维度有关。 | ||
140 | |||
141 | 每个组织必须定义其信息安全管理实践的范围,通常包括: | ||
142 | |||
143 | * IT系统与服务 | ||
144 | * IT基础设施和平台 | ||
145 | * 软件和应用程序 | ||
146 | * 网络基础结构,包括:IT网络,语音系统,无线系统等 | ||
147 | * 终端设备,例如电话,笔记本电脑和平板电脑,包括:所有硬件,固件,软件和应用程序 | ||
148 | * 物联网设备,通常具有网络连接和处理能力,并且可能也有与物理世界进行交互的传感器和驱动器 | ||
149 | * 物理基础设施,例如:建筑物,数据中心或制造设备 | ||
150 | * 业务流程 | ||
151 | * 人员,包括了解他们所产生的风险以及如何管理这些风险 | ||
152 | * 作为服务提供、管理和支持的一部分的合作伙伴和供应商 | ||
153 | * 数据和信息(无论是存储,处理还是传达的信息及其格式)。 | ||
154 | |||
155 | 在该范围中,信息安全管理实践应确保: | ||
156 | |||
157 | * 需要保护的资产应被识别 | ||
158 | * 可能影响这些资产的风险应被识别和分析 | ||
159 | * 采取适当措施管理这些风险 | ||
160 | * 监控和持续改进到位,以确保信息安全风险持续地被适当管理。 | ||
161 | |||
162 | 部分信息安全管理实践的重要内容在其他实践指南中进行了描述。表2.2 中列出了这些内容,作为本实践的参考供获取。 | ||
163 | |||
164 | 表2.2 与其他实践指南中描述的信息安全管理实践相关的活动 | ||
165 | |||
166 | (% style="width:571px" %) | ||
167 | |(% style="width:358px" %)**活动**|(% style="width:211px" %)**实践** | ||
168 | |(% style="width:358px" %)与客户,赞助商,监管机构和管理主体的战略沟通|(% style="width:211px" %)((( | ||
169 | 关系管理 | ||
170 | |||
171 | 组织变革管理 | ||
172 | ))) | ||
173 | |(% style="width:358px" %)与用户的运营沟通|(% style="width:211px" %)服务台 | ||
174 | |(% style="width:358px" %)建立和维护与供应商的合同|(% style="width:211px" %)供应商管理 | ||
175 | |(% style="width:358px" %)设计和实施产品和服务|(% style="width:211px" %)((( | ||
176 | 服务设计 | ||
177 | |||
178 | 软件开发和管理 | ||
179 | |||
180 | 基础设施和平台管理 | ||
181 | |||
182 | 服务验证和测试 | ||
183 | |||
184 | 部署管理 | ||
185 | |||
186 | 发布管理 | ||
187 | ))) | ||
188 | |(% style="width:358px" %)监控,发现潜在的安全事件|(% style="width:211px" %)监控和事态管理 | ||
189 | |||
190 | == **2.4 实践成功要素** == | ||
191 | |||
192 | **实践成功要素** | ||
193 | |||
194 | 需要为一项实践提供综合功能组件,以满足实践的目标。 | ||
195 | |||
196 | |||
197 | 实践成功要素(PSF)不仅仅是一项任务或活动,因为它包括服务管理全部四个维度的组件。活动的性质和实践中PSF的资源可能有所不同,但它们共同保障实践的有效性。 | ||
198 | |||
199 | 信息安全管理实践包括以下PSF: | ||
200 | |||
201 | * 开发和管理安全信息策略和计划 | ||
202 | * 缓解信息安全的风险 | ||
203 | * 执行和测试信息安全管理计划 | ||
204 | * 将信息安全嵌入到服务价值系统的所有方面。 | ||
205 | |||
206 | === 2.4.1 制定和管理安全信息策略和计划 === | ||
207 | |||
208 | 组织制定并维护安全信息策略和计划,以维持所需的安全信息水平。这些计划适用于组织内的每个人,并且有可能涉及服务的使用者,以及供应商和合作伙伴。因此,应该在整个组织内,保持沟通并理解适用的策略和计划。 | ||
209 | |||
210 | 组织应该了解内部和外部信息安全需求,以制定和管理其策略和计划。应对这些需求如何影响组织的资源、产品、服务和实践,以及是否使用了正确的信息安全控制进行评估。这些活动需要持续执行;由于信息安全要求和组织环境的性质不断变化。应在基于时间间隔和基于事态的基础上,持续审查需求的变化以及策略和计划的充分性。应基于这些审查来启动改进。 | ||
211 | |||
212 | 信息安全管理政策和计划可能涉及以下方面: | ||
213 | |||
214 | * 整体信息安全管理实践方法 | ||
215 | * 使用和滥用IT资产 | ||
216 | * 访问控制 | ||
217 | * 密码控制 | ||
218 | * 沟通和社交媒体 | ||
219 | * 恶意软件防护 | ||
220 | * 信息分类 | ||
221 | * 远程访问 | ||
222 | * 供应商访问组织的信息和资源 | ||
223 | * 知识产权 | ||
224 | * 记录管理和保留 | ||
225 | * 个人数据保护 | ||
226 | * 其他信息安全相关因素。 | ||
227 | |||
228 | 为了确保信息安全的有效管理,组织可以建立遵循相关标准(例如ISO / IEC 270012)的正式信息安全管理体系。 | ||
229 | |||
230 | |||
231 | === 2.4.2 缓解信息安全的风险 === | ||
232 | |||
233 | 信息安全管理实践包括信息安全风险的识别,分析和管理。 | ||
234 | |||
235 | 信息安全风险的识别包括识别服务价值系统的范围内的所有资产,然后识别这些资产的风险。威胁和脆弱性评估,架构和设计审查以及许多其他技术都可以支持风险识别。 | ||
236 | |||
237 | 信息安全风险的分析包括确定每个信息安全风险的可能性以及该风险的潜在影响。提供的数据可以评估成本、收益以及潜在控制的ROI。 | ||
238 | |||
239 | 信息安全管理包括定义和管理控制,这些控制管理着可能影响信息安全的多种多样的风险。这是与风险管理和其他针对风险的实践(例如容量和性能管理,可用性管理和服务连续性管理实践)一起执行的。商定的信息安全控制通常作为其他实践的一部分来实施,例如服务设计,软件开发和管理,基础设施和平台管理,架构管理,服务请求管理,持续改进,劳动力和人才管理,具体取决于控制的性质。 | ||
240 | |||
241 | 既定的策略和计划应驱动行为并实施控制以保持以下各项之间的平衡: | ||
242 | |||
243 | * 预防措施–确保不会发生安全事件 | ||
244 | * 检测–快速可靠地检测无法避免的事件 | ||
245 | * 纠正–在发现事件后从事件中恢复。 | ||
246 | |||
247 | 如果风险分析表明服务上的影响更早且更大,则应采取更多的预防措施。如果最初的影响较小,并且很久后才会进一步发展,则采用更经济有效方法投入到检测和纠正对策。 | ||
248 | |||
249 | 控制可能包括服务管理四维模型任何内容,例如: | ||
250 | |||
251 | * 组织和人员控制,例如培训,策略或职责分离 | ||
252 | * 价值流和流程控制,例如备份,补丁管理或同行评审 | ||
253 | * 信息和技术控制,例如防火墙,加密或防病毒软件 | ||
254 | * 合作伙伴和供应商控制,例如合同要求,流程审核或第三方认证。 | ||
255 | |||
256 | 选择信息安全对策时,应评估每个选择的有效性和效率。信息安全的对策有效性和效率必须得到持续控制和验证。 | ||
257 | |||
258 | |||
259 | === 2.4.3 演练和测试信息安全管理计划 === | ||
260 | |||
261 | 经验表明,未经测试的计划根本无法正常工作。因此,测试是整个信息安全管理实践的关键部分。这是确保计划和控制在实践中工作的唯一方法。 | ||
262 | |||
263 | 信息安全计划和控制应当被测试,以改进它的可读性和可用性。常规测试将发现缺陷和失效。这些发现可用于更新信息安全的计划和控制。 | ||
264 | |||
265 | 应该在计划的时间间隔内,以及策略、计划和控制发生重大变化时进行演练。信息安全事件的影响越大,演练应该越频繁。 | ||
266 | |||
267 | |||
268 | === 2.4.4 将信息安全嵌入到服务价值系统的所有方面 === | ||
269 | |||
270 | 信息安全管理实践应当被嵌入到服务价值系统的每一个部分中。 | ||
271 | |||
272 | |||
273 | ==== 2.4.4.1 指导原则 ==== | ||
274 | |||
275 | 使用ITIL 指导原则时,考虑使用本实践是非常重要的。例如: | ||
276 | |||
277 | * 聚焦价值:价值可以通过信息质量中的改进来实现 | ||
278 | * 协作和提升可视化:高层还会考虑信息的保密性。 | ||
279 | |||
280 | ==== 2.4.4.2 治理 ==== | ||
281 | |||
282 | 治理对于有效的信息安全管理实践至关重要。甚至最小的组织都应当针对以下内容建立本实践的治理: | ||
283 | |||
284 | * 确立组织对本实践的态度 | ||
285 | * 定义本实践的高层需求 | ||
286 | * 将高层需求传递给管理层 | ||
287 | * 监视组织以确保满足这些需求。 | ||
288 | |||
289 | ==== 2.4.4.3 服务价值链和价值流 ==== | ||
290 | |||
291 | 每个价值流应包括适当的信息安全管理实践活动。通常,它们将被嵌入到价值流的多个步骤以及服务价值链的多个点中。例如,考虑一个价值流,它创建了一个新的或经过重大变更的服务: | ||
292 | |||
293 | * 确认并记录服务需求(契动) | ||
294 | * 此步骤将包括记录对信息安全的服务需求 | ||
295 | * 决定是否对新的服务进行投入(计划) | ||
296 | * 在此步骤中,考虑可能对组织造成风险的信息安全事项 | ||
297 | * 设计新服务满足客户需求(设计和转换) | ||
298 | * 此步骤将包括设计和架构,以满足安全需求 | ||
299 | * 构建,配置或购买服务组件(获取或构建) | ||
300 | * 每个组件都需要被构建,配置或指定以满足安全需求 | ||
301 | * 部署服务组件以准备启动(设计和转换) | ||
302 | * 部署应该是安全的,以确保组件没有被篡改 | ||
303 | * 向客户和用户发布新的服务(交付和支持) | ||
304 | * 用户和IT人员需要进行培训,包括安全培训,作为发布的一部分。 | ||
305 | |||
306 | ==== 2.4.4.4 实践 ==== | ||
307 | |||
308 | 每个实践都需求包含信息安全管理的很多方面。这可能与服务管理四维模型某项有关。 | ||
309 | |||
310 | 通过实践定义的流程需要包含此实践的活动。例如,部署流程需要包括检查以确保软件组件不被篡改。 | ||
311 | |||
312 | 实践定义的角色需要包括此实践的技能。例如,软件开发人员可能需要具备满足已定义的安全标准的软件设计能力。 | ||
313 | |||
314 | 实践使用的信息和技术必须满足安全需求,并且通常需要嵌入安全措施。例如,事件管理实践中用于信息交换的工具可能需要保密,因此工作人员只能看到其所在组织的事件,而不能看到其他组织的事件。 | ||
315 | |||
316 | 支持一项实践的合作伙伴和供应商必须满足组织的信息安全需求。例如,提供服务连续性安排的合作伙伴,需要确保其员工不能使用作为连续性测试的一部分而提供给他们的数据。 | ||
317 | |||
318 | |||
319 | ==== 2.4.4.5 持续改进 ==== | ||
320 | |||
321 | 与其他所有实践一样,信息安全管理实践也需要持续改进。在IT服务面对的威胁和依赖程度逐步增长的情形下,不断监视并改进信息安全至关重要。 | ||
322 | |||
323 | 所有改进活动,即使是那些没有特定信息安全管理实践内容,也应评估其对信息安全造成的潜在影响。该评估作为惯例应成为任何改进活动的一部分。 | ||
324 | |||
325 | |||
326 | == **2.5** **关键指标** == | ||
327 | |||
328 | 应在每个实践所贡献的价值流的上下文中,评估ITIL实践的效益和绩效。与任何工具的绩效一样,只能在其所应用的上下文中评估该实践的绩效。然而,工具在质量方面差异很大。这些差异定义了工具根据其用途被使用时的潜力或性能。有关指标,关键性能或绩效指标(KPI)以及其他可以帮助实现此目标的技术的进一步指南,请参见度量和报告实践指南。 | ||
329 | |||
330 | 信息安全管理实践的关键指标已列入到其PSF。它们可以用作价值流上下文中的KPI,以评估实践对这些价值流的效果和效率的贡献。表2.3 中给出了一些示例。 | ||
331 | |||
332 | 表2.3 实践成功要素的关键指标示例 | ||
333 | |||
334 | |**实践成功要素**|**关键指标** | ||
335 | |制定和管理安全信息策略和计划|((( | ||
336 | 带有明确记录的信息安全要求的产品和服务的百分比 | ||
337 | |||
338 | 带有书面信息安全计划的产品和服务的百分比 | ||
339 | |||
340 | 定期更新信息安全计划的规则 | ||
341 | ))) | ||
342 | |缓解信息安全的风险|((( | ||
343 | 已执行分析和评价的信息安全风险的数量和百分比 | ||
344 | |||
345 | 通过实施控制将残留的风险降低到可接受的水平的信息安全风险的数量和百分比存在风险 | ||
346 | ))) | ||
347 | |演练和测试信息安全管理计划|((( | ||
348 | 在过去12个月中经过测试的信息安全管理计划的数量和百分比 | ||
349 | |||
350 | 测试信息安全管理计划后确定的改进活动数 | ||
351 | ))) | ||
352 | |在服务价值系统的所有方面都嵌入信息安全|((( | ||
353 | 治理主体在过去三个月中至少讨论过一次信息安全管理 | ||
354 | |||
355 | 包含信息安全特定步骤和活动的价值流的数量和百分比 | ||
356 | |||
357 | 在信息安全的流程和角色定义中包括特定步骤和活动的实践次数和百分比 | ||
358 | |||
359 | 包含安全评估的改进活动的数量和百分比 | ||
360 | ))) | ||
361 | |||
362 | 将指标正确汇总到复杂的指标中,将使数据更易于用于正在进行的价值流的管理,以及用于信息安全管理实践的定期评估和持续改进。没有单一的最佳解决方案。指标基于整体服务战略和组织的优先级,以及实践所贡献的价值流目标。 | ||
363 | |||
364 | |||
365 | |||
366 | |||
367 | ---- | ||
368 | |||
369 | = **3. 价值流和流程** = | ||
370 | |||
371 | |||
372 | == **3.1 价值流量贡献** == | ||
373 | |||
374 | 像任何其他ITIL 管理实践一样,信息安全管理实践也有助于多个价值流。重要的是要记住,价值流永远不会由单个实践形成。信息安全管理实践与其他实践相结合,可以为消费者提供高质量服务。信息安全管理实践为服务价值链的所有活动做出了贡献。图3.1 中显示了信息安全管理实践对服务价值链的贡献。 | ||
375 | |||
376 | (% style="text-align:center" %) | ||
377 | [[image:1639730997009-678.png]] | ||
378 | |||
379 | 图3.1 信息安全管理实践对价值链活动的贡献热力图 | ||
380 | |||
381 | |||
382 | == **3.2 流程** == | ||
383 | |||
384 | 每个实践可能包含一个或多个流程和活动,它们对于实现该实践的目标可能是必需的。 | ||
385 | |||
386 | |||
387 | **定义:流程** | ||
388 | |||
389 | 一组相互关联或交互的活动,可将输入转换为输出。流程接受一个或多个定义的输入,并将其转换为定义的输出。流程定义动作的顺序及其依赖。 | ||
390 | |||
391 | |||
392 | 许多信息安全管理实践活动被嵌入到其他实践的流程中。例如: | ||
393 | |||
394 | * 将安全设计为新的和更改的IT服务是服务设计实践的一部分 | ||
395 | * 将安全控制集成到应用程序中是软件开发和管理实践的一部分 | ||
396 | * 确保人员使用服务前被授权,同时也是服务请求管理一部分。 | ||
397 | |||
398 | 信息安全管理实践构建了两个流程: | ||
399 | |||
400 | * 安全事件管理 | ||
401 | * 审计和评审。 | ||
402 | |||
403 | === 3.2.1 安全事件管理 === | ||
404 | |||
405 | 安全事件有很多不同的类型。范围从单个客户设备受病毒影响,到对国家基础设施造成严重损害,或严重破坏高度敏感信息的攻击。 | ||
406 | |||
407 | 按照ITIL 事件管理实践指南中描述的事件处理和解决流程的规定,通常以与任何其他事件相同的方式来管理轻度安全事件。更严重的安全事件可能需要专业的管理,它可以基于本文件描述的流程。 | ||
408 | |||
409 | 每个组织应该定义一个标准,以确定事件是否需要专业的安全事件管理,或者可以使用常规事件处理和解决流程进行管理。 | ||
410 | |||
411 | 该流程包括表3.1 中列出的以下活动,并将以下输入转换为输出。 | ||
412 | |||
413 | 表3.1 安全事件管理流程的输入、活动和输出 | ||
414 | |||
415 | |**关键输入**|**活动**|**关键输出** | ||
416 | |((( | ||
417 | 信息安全策略 | ||
418 | |||
419 | 服务和资产信息 | ||
420 | |||
421 | 监控和事态工具 | ||
422 | |||
423 | 安全事件和事态管理(SIEM)工具 | ||
424 | |||
425 | 从服务台进行升级 | ||
426 | |||
427 | 已知的数据和应用程序的良好来源 | ||
428 | )))|((( | ||
429 | 准备 | ||
430 | |||
431 | 检测和报告分类和分析 | ||
432 | |||
433 | 控制和恢复 | ||
434 | |||
435 | 事件后活动 | ||
436 | )))|((( | ||
437 | 事件响应计划 | ||
438 | |||
439 | 供应商合同 | ||
440 | |||
441 | 事件通知监管机构,治理机构或其他相关方 | ||
442 | |||
443 | 恢复信息和服务 | ||
444 | |||
445 | 事件报告 | ||
446 | |||
447 | 改进建议 | ||
448 | ))) | ||
449 | |||
450 | 图3.2 显示了流程的工作流图 | ||
451 | |||
452 | (% style="text-align:center" %) | ||
453 | [[image:1639731069547-322.png]] | ||
454 | |||
455 | 图3.2 安全事件管理流程的工作流 | ||
456 | |||
457 | |||
458 | 这些活动可能会由组织内的许多人以不同级别的形式执行。 | ||
459 | |||
460 | 表3.2 提供了流程活动的示例 | ||
461 | |||
462 | 表3.2 安全事件管理流程的活动 | ||
463 | |||
464 | (% style="width:755px" %) | ||
465 | |(% style="width:127px" %)实现价值|(% style="width:626px" %)例 | ||
466 | |(% style="width:127px" %)准备|(% style="width:626px" %)((( | ||
467 | 在安全事件发生之前,组织必须执行操作以为将来可能发生的安全事件做准备。这包括: | ||
468 | |||
469 | 定义和传达安全事件管理的策略和程序 | ||
470 | |||
471 | 确定可能需要特定响应计划的关键服务和资产 | ||
472 | |||
473 | 允许在安全事件期间进行的沟通,包括与以下机构的沟通:治理机构,监管机构,执法机构,新闻界,客户,内部人员,用户,供应商以及任何其他受影响的利益相关者 | ||
474 | |||
475 | 定义如何报告安全事件和违规,以识别需要管理的威胁和漏洞,并记录特定场景的事件响应计划 | ||
476 | |||
477 | 让合作伙伴和供应商提供支持特定场景可能需要的产品和服务 | ||
478 | |||
479 | 测试事件响应计划 | ||
480 | ))) | ||
481 | |(% style="width:127px" %)检测和升级|(% style="width:626px" %)((( | ||
482 | 信息安全事件可能是:由监控工具检测,受关联工具支持以及受安全事件和事态管理(SIEM)工具支持。事件也可由人员发现;可能会向服务台或安全事件响应小组报告,这取决于谁检测到事件以及事件的性质 | ||
483 | |||
484 | 根据特定的事件响应计划,将事件升级到适当的人员或团队。这可能涉及组建计算机安全事件响应团队(CSIRT) | ||
485 | |||
486 | 如果需要,会将初始通知发送给适当的监管或治理机构 | ||
487 | ))) | ||
488 | |(% style="width:127px" %)分类和分析|(% style="width:626px" %)((( | ||
489 | 可能需要保留证据,以备将来使用司法程序。为防止污损,必须在进行任何分析之前收集司法数据 | ||
490 | |||
491 | 通过检查系统,端点,应用程序,日志文件等,可以确定安全事件的性质和严重性 | ||
492 | |||
493 | 如果需要,则在了解事件的性质和严重性后,可以将进一步的通知发送给监管机构或治理当局 | ||
494 | ))) | ||
495 | |(% style="width:127px" %)遏制和恢复|(% style="width:626px" %)((( | ||
496 | 受影响的系统和服务与Internet和/或组织的其余部分隔离。这样可以进行进一步的分析,同时限制了风险的进一步破坏 | ||
497 | |||
498 | 如果可能,则使用其他可选系统恢复服务 | ||
499 | |||
500 | 分析完成后,将关闭受影响的系统,擦除存储,并从知名且可靠的来源重建系统 | ||
501 | |||
502 | 如果可以在没有其他事件的威胁或最初事件造成进一步损坏的情况下运行业务,则认为流程已恢复 | ||
503 | ))) | ||
504 | |(% style="width:127px" %)事件后活动|(% style="width:626px" %)系统和服务被监视以保证威胁已被移除。进行经验教训分析以识别改进机会。事件报告完成创建并适当分享 | ||
505 | |||
506 | === 3.2.2 审计和评审 === | ||
507 | |||
508 | 审计和评审会定期执行并遵循时间表。重大事件或威胁评估或脆弱性评估的发现也可能触发它。 | ||
509 | |||
510 | 该流程包括表3.3 中列出的活动,并将以下输入转换为输出。 | ||
511 | |||
512 | |||
513 | 表3.3 审计和评审流程的输入、活动和输出 | ||
514 | |||
515 | |关键输入|活动|关键输出 | ||
516 | |((( | ||
517 | 业务流程信息 | ||
518 | |||
519 | 威胁评估信息 | ||
520 | |||
521 | 服务和资产信息 | ||
522 | |||
523 | 外部标准 | ||
524 | |||
525 | 当前控制 | ||
526 | |||
527 | 脆弱性评估信息 | ||
528 | )))|((( | ||
529 | 识别对业务,技术或威胁环境的变更 | ||
530 | |||
531 | 确定缺少的控制 | ||
532 | |||
533 | 评估控制效果 | ||
534 | |||
535 | 创建审计报告 | ||
536 | )))|((( | ||
537 | 改进建议 | ||
538 | |||
539 | 审计报告 | ||
540 | ))) | ||
541 | |||
542 | (% style="text-align:center" %) | ||
543 | [[image:1639731110544-225.png]] | ||
544 | |||
545 | 图3.3 审计和评审流程的工作流 | ||
546 | |||
547 | |||
548 | 图3.3 显示了流程的工作流图。 | ||
549 | |||
550 | |||
551 | 这些活动可能由内部或外部审核员执行。许多组织执行内部审计并实施改进。然后,外部审核员可以执行更正式的审计。 | ||
552 | |||
553 | |||
554 | 表3.4 提供了流程活动的示例 | ||
555 | |||
556 | |||
557 | 表3.4 审计和评审流程的活动 | ||
558 | |||
559 | [[image:1639731180596-486.png]] | ||
560 | |||
561 | |||
562 | |||
563 | |||
564 | ---- | ||
565 | |||
566 | = **4.组织和人员** = | ||
567 | |||
568 | |||
569 | == **4.1 角色,能力和责任** == | ||
570 | |||
571 | 实践指南没有描述实践管理的角色,例如实践所有者,实践领导或实践教练。相反,他们专注于每个特定实践的专门角色。每个角色的结构和命名都可能因组织不同而不同,因此ITIL中定义的任何角色都不应视为强制性的或建议的。 | ||
572 | |||
573 | 请记住,角色不是职务。一个人可以担任多个角色,一个角色可以分配给多个人。 | ||
574 | |||
575 | 角色在流程和活动中被描述。每个角色都具有基于表4.1 中所示的模型的能力类型。 | ||
576 | |||
577 | 表4.1 能力代码和类型 | ||
578 | |||
579 | [[image:1639731273682-968.png]] | ||
580 | |||
581 | |||
582 | === 4.1.1 首席信息安全官角色 === | ||
583 | |||
584 | 许多组织都有负责信息安全管理实践的董事会成员。该角色通常称为首席信息安全官(CISO)。 | ||
585 | |||
586 | CISO典型负责: | ||
587 | |||
588 | * 在了解组织业务战略的基础上,建立组织的总体信息安全战略,以及可能影响其的信息安全风险 | ||
589 | * 确保组织对信息安全采取均衡的方法,提供足够的保护,而不会对开展业务的能力造成不利影响 | ||
590 | * 有关安全信息的战略沟通给董事会和其他利益相关者例如监管机构,执法部门,媒体,客户,供应商和合作伙伴 | ||
591 | * 制定信息安全政策和程序 | ||
592 | * 监督负责安全信息所有其他方面的人员,包括: | ||
593 | ** 开发,测试和改进流程,尤其是安全事件管理 | ||
594 | ** 选择,测试和部署安全产品,例如防火墙或防病毒软件 | ||
595 | ** 为采购、开发,测试,部署定义标准和指南并持续管理具有安全影响的基础架构和应用程序,例如服务器,操作系统,SaaS产品,内部应用程序,中间件和客户设备 | ||
596 | ** 运维活动,例如安全事态监控和安全产品例行检查。 | ||
597 | |||
598 | === 4.1.2 信息安全管理中涉及的其他角色 === | ||
599 | |||
600 | 下表4.2 列出了信息安全管理实践中可能涉及的其他角色,以及相关的能力类型和特定技能。 | ||
601 | |||
602 | 表4.2 负责信息安全管理的角色示例活动 | ||
603 | |||
604 | [[image:1639731364245-481.png]] | ||
605 | |||
606 | [[image:1639731403869-829.png]] | ||
607 | |||
608 | [[image:1639731417402-261.png]] | ||
609 | |||
610 | |||
611 | === 4.1.3 所有角色的安全能力 === | ||
612 | |||
613 | 组织中的每个人都对信息安全管理实践负有责任。每个角色应该包括一些安全管理要求。那些了解信息安全管理实践功能的人可以: | ||
614 | |||
615 | * 通过遵循所有必需的策略,实施必需的控制以及通知和报告漏洞来防止信息安全事件和违规 | ||
616 | * 通过通知和报告异常的行为技术,人员或供应商来检测信息安全事件和违规 | ||
617 | * 通过在发生事件时遵循必需的流程和过程来更正安全事件和违规信息。 | ||
618 | |||
619 | 如果人员没有适当的技能,能力和动力,其也可以通过消极的方式为其中的每一项做出贡献。可以做很多事情来帮助确保组织中的每个人都为信息安全做出积极贡献。 | ||
620 | |||
621 | |||
622 | ==== 4.1.3.1 安全意识培训 ==== | ||
623 | |||
624 | 安全意识培训应帮助员工识别风险并采取适当的措施。培训通常包括以下问题: | ||
625 | |||
626 | * 用户身份验证,密码安全,多因素和生物特征识别 | ||
627 | * 安全的Web浏览和社交媒体的使用 | ||
628 | * 电子邮件,电话和其他通讯渠道的适当使用 | ||
629 | * 端点安全,包括电话,平板电脑,笔记本电脑,可移动媒体的使用,个人设备等 | ||
630 | * 远程和移动工作,包括使用公共Wi-Fi | ||
631 | * 社会工程学,网络钓鱼和身份盗窃 | ||
632 | * 恶意软件,包括:病毒,勒索软件,键盘记录程序,广告软件,间谍软件等 | ||
633 | * 高级持续性威胁 | ||
634 | * 个人身份信息(PII)和数据隐私 | ||
635 | * 信息分类以及对信息和其他资产的适当处理 | ||
636 | * 安全事件报告和管理。 | ||
637 | |||
638 | 了解组织信息安全政策和控制的相关内容。安全意识应定期进行培训,尤其是新员工。一些组织每年进行一次进修培训,涵盖所有必需的材料。另外一些组织则提供更多的定期培训,这些培训每次仅涵盖部分材料,但一年的课程会包括所需的所有内容。 | ||
639 | |||
640 | |||
641 | ==== 4.1.3.2 每个工作说明中的安全要求 ==== | ||
642 | |||
643 | 每个工作说明应包括适当的安全活动。其中一些活动将是通用的,并且每个人都相同。其他将特定于组织内部人员拥有的角色。 | ||
644 | |||
645 | |||
646 | ==== 4.1.3.3 定期强化安全信息 ==== | ||
647 | |||
648 | 定期强化安全信息可确保安全意识在关键时刻处在员工头脑中的最前沿。这种强化可以采用海报,屏幕保护程序,电子邮件,管理简介或其他任何适合组织文化的方法。 | ||
649 | |||
650 | |||
651 | |||
652 | == **4.2 组织结构和团队** == | ||
653 | |||
654 | 在拥有专门IT部门的组织中,CISO的角色通常不在IT范围内,以确保实践的范围不仅限于IT。通常,CISO将有许多直接报告人员,他们能够制定策略和流程,执行安全审计并向其他人员提供安全信息指南。 | ||
655 | |||
656 | 许多组织都有专门的IT安全团队,该团队在整个组织中提供专业知识,但是在其他IT团队中拥有安全信息专业知识也很重要。例如: | ||
657 | |||
658 | * 服务架构师和服务设计师必须能够构架和设计安全的IT服务。他们必须拥有足够的知识和理解力才能自己完成大部分工作,即使他们可能需要专业安全工作人员的帮助。 | ||
659 | * 应用程序开发人员必须能够编写安全代码。这需要理解安全编码指南以及应避免的常见错误。 | ||
660 | * 服务台工作人员必须能够识别安全事件,并根据组织的安全策略和安全事件响应计划采取适当行动。 | ||
661 | * 所有员工都必须知晓检测常见安全攻击的责任,并知道如何应对这些攻击。 | ||
662 | |||
663 | ---- | ||
664 | |||
665 | = **5. 信息和技术** = | ||
666 | |||
667 | |||
668 | == **5.1 信息交换** == | ||
669 | |||
670 | 信息安全管理的效果取决于所使用信息的质量。该信息包括但不限于以下信息: | ||
671 | |||
672 | * 消费者的业务流程 | ||
673 | * 服务的架构和设计 | ||
674 | * 合作伙伴和供应商,以及它们提供的服务信息 | ||
675 | * 有关信息安全的法规要求 | ||
676 | * 市场上可能与信息安全有关的技术和服务 | ||
677 | * 安全标准和最佳实践 | ||
678 | |||
679 | 该信息可以采用多种形式。实践的关键输入和输出在第3节中列出。 | ||
680 | |||
681 | |||
682 | |||
683 | == **5.2** **自动化和工具** == | ||
684 | |||
685 | 在某些情况下,信息安全管理实践可以从自动化中受益。在表5.1 中提及的解决方案概述可能有效。 | ||
686 | |||
687 | 表5.1 信息安全管理活动的自动化解决方案 | ||
688 | |||
689 | [[image:1639731786760-352.png]] | ||
690 | |||
691 | [[image:1639731814570-443.png]] | ||
692 | |||
693 | |||
694 | |||
695 | |||
696 | ---- | ||
697 | |||
698 | = **6. 合作伙伴和供应商** = | ||
699 | |||
700 | 仅使用组织自己的资源来提供的服务很少见。大多数(如果不是全部)依赖于其他服务,这些服务通常由组织之外的第三方提供(请参阅ITIL Foundation 2.4 章节:服务关系模型)。由支持服务引入的关系和依赖在ITIL 实践指南的供方管理和服务级别管理中进行了描述。 | ||
701 | |||
702 | 合作伙伴和供应商可能会提供关键产品和服务组件。服务提供者需求与合作伙伴和供应商协商并同意信息安全的要求,以满足信息安全的需求。 | ||
703 | |||
704 | 合作伙伴和供应商还可能提供安全服务和解决方案的信息,例如:脆弱性评估,威胁评估,安全事件管理,提供安全相关基础架构或应用程序等。在这种情况下,他们还应该参与这些服务和解决方案的测试和审查。 | ||
705 | |||
706 | 如果供应商可以访问组织的网络,服务器或其他资源,这可能是安全违规行为。此风险需求将被识别和控制。通常,这是通过以下方式控制的: | ||
707 | |||
708 | * 网络隔离:防止供应商访问网络的更敏感部分 | ||
709 | * 强身份验证和加密功能:防止供应商访问敏感的数据和系统 | ||
710 | * 具有定期审核的合同条款:确保供应商理解对他们的期望并满足这些期望。 | ||
711 | |||
712 | ---- | ||
713 | |||
714 | = **7. 重要提醒** = | ||
715 | |||
716 | 实践指南的大部分内容都应作为组织在建立和构建自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录,而不是答案列表。使用实践指南的内容时,组织应始终遵循ITIL 指导原则: | ||
717 | |||
718 | * 聚焦价值 | ||
719 | * 从你所处的地方开始 | ||
720 | * 基于反馈迭代推进 | ||
721 | * 协作和提升可视化程度 | ||
722 | * 通盘思考和工作 | ||
723 | * 保持简单实用 | ||
724 | * 优化和自动化。 | ||
725 | |||
726 | 有关指导原则及其应用程序的更多信息,请参见以下内容的第4.3节。 | ||
727 | |||
728 | //ITIL^^®^^Foundation:ITIL 4版。// | ||
729 | |||
730 | |||
731 | |||
732 | |||
733 | ---- | ||
734 | |||
735 | = **8. 致谢** = | ||
736 | |||
737 | AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员: | ||
738 | |||
739 | |||
740 | == **8.1 作者** == | ||
741 | |||
742 | 罗曼·朱拉夫列夫(Roman Jouravlev),斯图尔特·兰斯(Stuart Rance) | ||
743 | |||
744 | |||
745 | == **8.2 审稿人** == | ||
746 | |||
747 | 迪纳拉·阿迪尔巴耶娃(Dinara Adyrbayeva),帕维尔·德明(Pavel Demin) | ||
748 | |||
749 |