信息安全内部文档指南。 什么,如何以及为什么



之前的一篇文章中,我们谈到了为审查员形成一套有关个人数据保护的文件的问题。 我们提供了到文档模板的链接,但是非常肤浅地关注信息安全文档的主题。

在本文中,我想在个人数据和一般信息保护方面更详细地公开此主题。 操作员应携带哪些文件,这是可选的。 该文件或该文件的需求来自何处。 在文档中写什么,什么不值得。 在这个主题下,削减了很多字母。

捍卫“纸张”安全的几句话


由于本文将重点讨论所谓的“纸质”安全性,因此我想立即概述一下我们在信息安全性这一部分的立场。

对于许多使用“手”进行操作的技术人员而言,这种“纸面”安全性通常会导致他们的拒绝和忽视。 但是,很奇怪的是,当这样的技术人员可以使用新的硬件或软件(有时在一个产品中同时使用这两种产品)时,他想首先了解这种技术奇迹的文档。

这种不屑一顾的立场最普遍的理由是,所有这些文件都是为了遵守法律要求而只是为了展示而做的,这是浪费时间,文件必须得到支持,但没有人会这样做等等。

不幸的是,这一立场并非毫无根据。 多年来,无论是在本地安全卫士中,还是在被许可人,集成商和其他有关方面中,都对信息安全文档采取了相同态度的可悲做法。 结果,形成了一个恶性循环-由于忽略了文档而使文档变得无用,而又由于文档无用而导致文档被忽略。

由于经常由远离信息技术的人来编写信息安全文档,这在一定程度上加剧了这种情况。 毕竟,如何在不了解虚拟化工作原理的情况下撰写关于保护虚拟化工具的章节?

为了扭转这种局面,有必要制作良好,内容丰富且有用的文件。 同时,这些文件必须符合适用的信息保护法规。 让我们看看所有这些可以做什么。

一些澄清


首先,为了消除不必要的问题和猜想,我们认为有必要澄清几点。

  1. 在本文中,我们将仅考虑内部组织和行政文件(以下简称“ ARD”)以保护信息。 设计,认证和其他文件将不予考虑。
  2. 尽管威胁模型在此处 ,我们也不会考虑。 威胁模型的开发是另一个故事。 在评论中写-您是否需要有关在Habré上开发威胁模型的手册?
  3. 本文将依靠我们的模板集。 它不是某种标准或公认的集合。 这一套反映了我们开发ARD的纯粹方法。 由于立法通常没有对此做出任何具体规定,因此您可能对文件的完整性和内容有自己的看法,这很正常!
  4. 模板中可能存在错误和错别字。 我们自己不断改进和完善它们。
  5. 在满足要求的背景下,个人数据(152-和法规)和州信息系统(FSTEC的第17项)的主题将受到主要影响。 此外,金融机构还有另一个故事(俄罗斯联邦中央银行的要求)和各种标准(ISO 2700x等)-我们在这里不予考虑。

文件完整性




如果您依靠立法来保护信息,则几乎无话可说我们应该在哪里开发什么文件,因此我们必须依靠各种间接提示。

例如,我们给出了第152-FZ号法律“关于个人数据”第19条的第2部分。 纯文本将是法律文本,以斜体显示-作者的注释。
2.实现了个人数据的安全性,尤其是:

1)确定在个人数据信息系统中对个人数据的安全威胁; (需要威胁模型)

2)采取组织和技术措施以确保在满足满足保护个人数据要求所必需的个人数据信息系统中处理个人数据期间的安全,其实施确保了俄罗斯联邦政府确定的个人数据安全级别; (组织措施大部分是我们的文件,再加上这里,它们使我们能够阅读更多的章程)

3)通过使用程序来评估以规定方式通过的信息保护设施的符合性;

4)在启动个人数据信息系统之前,评估为确保个人数据的安全而采取的措施的有效性;

5)考虑到机器载体的个人数据; (显然,您需要某种会计日记帐和已制定的机器媒体会计规则)

6)发现未授权访问个人数据并采取措施; (有必要制定一些规则来检测事件并消除其后果,可能有必要任命一个事件响应小组)

7)恢复因未经授权访问而修改或破坏的个人数据; (需要备份和还原规则)

8)建立访问在个人数据信息系统中处理的个人数据的规则,以及在个人数据信息系统中注册和记录对个人数据执行的所有操作的规则; (可以根据系统中的角色来完成对数据访问系统的开发,只是软件本身应该能够维护谁曾经访问过哪些数据的日志)

9)控制为确保个人数据的安全性和个人数据信息系统的安全性而采取的措施。 (我们需要一个确定的计划以进行定期监视,此外,可能还需要记录这种监视结果的日志)
在这个例子中,我们想表明不同之处:法律是如何制定的,以及实际上法律对我们的要求。 在这里,我们没有看到直接的要求“操作员必须开发威胁模型”,但是由于记录了所有要求的实现,因此该要求仍然来自152-FZ。

更具体地说,FSTEC向我们介绍了ARD的完整性和内容。 2014年,该监管机构发布了一种方法性文件,即《国家信息系统中的信息安全措施》。 如果您对FSTEC的第17、21或其他顺序的措施的执行顺序不了解(是的,尽管该文档是针对GIS的,但是大多数措施与FSTEC一致),那么无讽刺的文档非常有用。该文档可能会变得更加清晰。

因此,在本文档中,FSTEC更加广泛地概述了确保信息安全的措施,并且经常可以找到以下文本:
组织和行政文件中对用于标识和认证用户的规则和程序进行了规定,以保护信息。 (IAF.1)

管理用户帐户的规则和过程在运营商的组织和管理文档中得到了规定,以保护信息。 (UPD.1)

运营商的组织和行政文件中对管理信息流的规则和程序进行了规定,以保护信息。 (UPD.3)
好了,已经有些了,但是这些规则和程序是完整的。

结果,我不得不用一块盘子拼写自己,把所有文件的所有要求写出来,并就实现和不实现做笔记。



本节的主要思想是信息保护立法中有大量要求,其中许多要求的实施都需要记录在案。 是否为每个需求创建单独的文档,或者将所有内容合并为一个大的“ IS策略”,这取决于每个人。 不需要根据要求而是根据实际需要在文档中注册的所有其他附加内容都没有任何问题。

顺便说一下,请注意在表格和文档本身中,某些部分或段落标记为“ K1”或“ K2 +”。 这意味着只有第2类及以上的信息系统或第一个(最大类)的信息系统才需要一节或段落。 所有未标记的操作在所有状态信息系统和ISPD中执行。

同样很明显,例如,如果信息系统的结构和功能特性或其他初始条件需要,则可以删除某些部分甚至整个文档。 例如,如果没有,我们将删除视频监视。 或者,如果未应用,则删除与保护虚拟化工具有关的所有部分。

我们的模板分为4个文件夹:

常规 -需要为所有系统(如适用)开发的文档,无论是ISPDn,GIS,自动化过程控制系统还是KII对象。

仅GIS-状态信息系统或市政信息系统的文档,而GIS和MIS仅需要唯一的文档。

PD-有关个人数据保护的文件,并根据有关个人数据保护的法律进行。 例如,如果我们拥有处理个人数据的GIS,那么我们必须从所有文件夹制作文档。

CIPF-与使用加密工具有关的文件,是实施FSB监管文件所需的文件,适用于所有使用经过认证的加密信息保护手段的系统。

让我们更详细地考虑文档,它们来自何处以及它们满足什么要求。

一般


01任命负责人的命令和对这些人的指示


该命令指定:负责组织个人数据处理的人员和安全管理员。

联邦法律第18.1条规定了任命第一名的必要性:
1.操作者必须采取措施...这些措施可能包括但不限于:

1)由法人实体的运营商任命负责组织个人数据处理的人员;
安全管理员-此朋友的需要是由于,例如,FSTEC第17号命令的第9条:
为了确保保护信息系统中包含的信息,运营商会任命负责信息保护的结构单位或官员(雇员)。
这些人的不同之处在于,“负责人”在纸质部分更多,而“管理员”在技术部分。

为了使负责人和管理员了解其任务和权限,他们有权获得指示。

02关于指定信息安全事件响应小组(GRIIB)的命令和响应指示


SRIMS的缩写虽然有点荒谬,但相当正式,是由GOST R ISO / IEC TO 18044-2007“信息技术”引入的。 安全方法和工具。 信息安全事件管理。”

许多监管文件都要求提供文件。 例如,《个人数据法》的第19条。 但是,更详细的信息是根据FSTEC的命令披露的。
FSTEC第17号命令:

18.2。 在识别和响应事件的过程中:

  • 确定负责识别事件并做出响应的人员;
  • 检测和识别事件,包括拒绝服务,硬件,软件和信息保护工具运行失败(重启),违反访问控制规则,收集信息的非法行为,恶意计算机程序(病毒)的引入和其他事件,导致事件;
  • 及时通知负责识别事件并做出响应的人员有关用户和管理员在信息系统中发生的事件的信息;
  • 分析事故,包括确定事故的来源和原因,并评估其后果;
  • 规划和采取措施消除事件,包括在拒绝服务或发生故障后恢复信息系统及其部分,消除违反访问控制规则,收集信息的非法行为,引入恶意计算机程序(病毒)和其他事件的后果导致事件;
  • 规划并采取措施以防止再次发生事件。
相同的文件还涉及许多组织措施,例如,RSB.1“确定要记录的安全事件及其存储期限”和SSB.2“确定有关要注册的安全事件的信息的组成和内容”。 所有这些内容都可以在事件响应说明中指出,以免产生单独的文档。

03用户手册


此类指令的必要性的主要法律依据是立法中关于指导用户信息安全问题的所有地方。 例如,《个人数据法》第18.1条的第1部分:
6)使操作员的员工直接处理个人数据,并熟悉俄罗斯联邦关于个人数据的法律规定,包括对个人数据的保护要求,定义操作员有关个人数据处理政策的文件,有关处理个人数据的当地法规, 以及(或)对这些员工进行培训。
对此类文档的间接需求是对可能的信息安全事件的用户责任进行合法注册。 如实践所示 ,在不存在此类指令和(或)用户不熟悉该指令的情况下,违反IS要求的用户很可能不会追究责任。

至于文档本身,我们在这里决定不给用户带来不必要的废话,以使文档不会太难理解并且不仅对企业的信息安全有用,而且对个人生活中的信息安全问题也很有用。 例如,他们用示例描述了社会工程学的方法。

05信息安全政策


可能是整套文档中数量最多的文档之一。 还记得上面我们写过“保护GIS中信息的措施”文档以及需要在ARD中编写的大量“规则和程序”吗? 实际上,“ IB政策”实际上是所有此类规则和程序的集合。

在这里,也许值得停止使用“政治”一词。 人们经常被告知,我们的“政治”过于针对性,但实际上,具有该名称的文档应该更抽象,更高级。 可能是这样,但是在这里,作为安全人员,首先,具有技术背景的单词“ Politics”与例如域的组策略相关联,而该组策略又与特定的规则和设置相关联。

实际上,将这种文件称为什么并不重要。 如果您不喜欢“策略”一词,则可以将其重命名为“信息安全规则和过程”。 这不是重点。 最主要的是,这些规则和程序应该已经在本文档中明确阐明。

我们将在这里详细介绍。

如果打开文档并开始使用它,您会发现在某些地方没有特定的文本空白,而是一个干燥的“描述”。 这是因为无法描述某些事物,因此文本同时适合至少一半的特定信息系统。 对于每种情况,最好分别描述这些部分。 这就是为什么我们仍然对各种自动文档填充程序持怀疑态度的原因。

在正文中,所有内容应该整体上都清楚,我想稍微介绍一下应用程序。

要求更改用户列表

在一个高度官僚的系统中,这种用于跟踪用户及其凭据的程序似乎很多,但是,我们经常遇到这种情况有助于改进信息安全事件调查的情况。 例如,有必要确定最初授予用户什么权限。 当提出从应用程序到IS策略的应用程序时,事实证明一个帐户的权限得到了未经授权的增加。

在任何情况下,由每个操作员决定是否执行这样的用户注册程序。 在这里,可能值得一提的是,任何立法行为都不需要完全按照我们的IS政策模型中明确描述的方式进行操作。 文档模板最有可能是最严格和令人沮丧的选择。 然后每个人都自己决定-在哪里拧松螺母,在哪里拧紧螺母。

关于访问权和人员名单的规定

对于任何系统管理员来说,区分用户访问权限都是显而易见的措施。 : .2 « (, , ), (, , ) », .4 « () , , » .

, .

. , , . . – , « » , « » , « » .



.3 « (, , , ) , , ».

, , , « ». , « » - . , .



.3 « () () ». , , .

, - . - - .

. , , .



. « 2 : , , ». , , , « , » .

10 .

( ), . , 2 19 « »:
, :

7) , ;
:
.4


. , , , .

, :
.3 , ,

06


: .2 « , , , , ».

, , , . ., . , , . , , «», , .

07 ...


2 – . 2 , .

: « , , , , ?». , – . , , , - . .

– , . , 1 18.1 « »:
1. … , , :

4) () , , , ;

08-14 ...




08-10 . :

  • , , . .;
  • (, , , . .);
  • (, HDD, ).

. . , . , - . , , , 09 10 .

, . . .

, . . , , . .


01


, . , 17- « , ». , , , « ».

, .

02-03


. , , .

, , .

– , , .

04


17- , ( ) .


01


, , . , , . , . , - .

02


3 « » . , , , . . , .

, , , ( , ). .

03


, . , . , , , (, ). , .

04


! : « ?».

2 18.1 « »:
, , . , - , - , , , - .
, , . , , , .

05-06



, . : , , . , .

07


- , , , .

. . — , – . , , , , .

, . :
1. , ( — ), (), , , , , , .

2. , .
, . « » :
4) ;


. , – , ( – ).

08


, , , , . , , . . .

09


. . , , . .

10


, . , 4 9 « ».

11


, , . - . , . , — , , .

12


, ( , ).

13


. – . , .


, . , , . ( 2001 ), - , , . , .

结论


, . , , , . - , . , , , , « ».

Source: https://habr.com/ru/post/zh-CN456508/


All Articles