Гайд по внутренней документации по информационной безопасности. Что, как и зачем / Блог компании Информационный центр / Хабр

08 приказ о комиссии по уничтожению пдн и форма акта уничтожения

Документ по большей части относится к неавтоматизированной обработке, то есть, например, к уничтожению личных дел сотрудников, срок хранения которых истек. Эти документы лучше утвердить, даже если вы еще ничего не уничтожали, т. к. проверяющие часто требуют их наличия.

01 положение о защите и обработке пдн

Основной документ по защите персональных данных, где мы стараемся прописать максимум аспектов обработки ПДн, предусмотренных законодательством. Здесь мы прописываем, чьи данные, какие данные и с какими целями мы обрабатываем. Права и обязанности субъектов ПДн, права и обязанности оператора ПДн и так далее.

01 приказ необходимости защиты информации

Нас часто спрашивают, зачем вообще нужен такой приказ. Дело в том, что 17-м приказом ФСТЭК первым мероприятием по формированию требований к защите информации установлено некое «принятие решения о необходимости защиты информации, содержащейся в информационной системе».

Обратите внимание, что для государственных и для муниципальных информационных систем шаблоны разные.

01 приказ о назначении ответственных лиц и инструкции этим лицам

Этим приказом назначаются: ответственный за организацию обработки персональных данных и администратор безопасности.

Необходимость назначения первого обусловлена статьей 18.1 федерального закона:

1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:

1) назначение оператором, являющимся юридическим лицом, ответственного за организацию обработки персональных данных;

Администратор безопасности – необходимость этого товарища обусловлена например пунктом 9 приказа ФСТЭК №17:

Для обеспечения защиты информации, содержащейся в информационной системе, оператором назначается структурное подразделение или должностное лицо (работник), ответственные за защиту информации.

Отличаются эти лица тем, что «ответственный» больше по бумажной части, а «администратор» по технической.

Для того чтобы ответственный и администратор понимали свои задачи и полномочия им полагаются инструкции.

02 правила рассмотрения запросов

Глава 3 закона «О персональных данных» полностью посвящена правам субъекта персональных данных. Субъект ПДн имеет право писать различные запросы оператору ПДн, например, уточнить какие его данные и с какой целью обрабатываются, попросить прекратить обработку его персональных данных и т. д. Законом так же обозначены максимальные сроки, в которые оператор ПДн должен уложиться с ответом.

Соответственно, неплохо было бы иметь под рукой внутренний документ, регламентирующий правила и сроки рассмотрения таких запросов, а также имеющий в своем составе шаблоны ответов субъектам (как положительных, так и отрицательных). Это сильно упростит жизнь ответственному за организацию обработки персональных данных.

02 приказ о назначении группы реагирования на инциденты информационной безопасности (грииб) и инструкция по реагированию

Сокращение ГРИИБ хоть и немного смешное, но вполне себе официальное, введено ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности».

Необходимость документов необходима целым рядом нормативно-правовых документов. Например, той же статьей 19 закона «О персональных данных». Но более подробно реагирование на инциденты раскрывается в приказах ФСТЭК.

Приказ ФСТЭК №17:

18.2. В ходе выявления инцидентов и реагирования на них осуществляются:

• определение лиц, ответственных за выявление инцидентов и реагирование на них;
• обнаружение и идентификация инцидентов, в том числе отказов в обслуживании, сбоев (перезагрузок) в работе технических средств, программного обеспечения и средств защиты информации, нарушений правил разграничения доступа, неправомерных действий по сбору информации, внедрений вредоносных компьютерных программ (вирусов) и иных событий, приводящих к возникновению инцидентов;
• своевременное информирование лиц, ответственных за выявление инцидентов и реагирование на них, о возникновении инцидентов в информационной системе пользователями и администраторами;
• анализ инцидентов, в том числе определение источников и причин возникновения инцидентов, а также оценка их последствий;
• планирование и принятие мер по устранению инцидентов, в том числе по восстановлению информационной системы и ее сегментов в случае отказа в обслуживании или после сбоев, устранению последствий нарушения правил разграничения доступа, неправомерных действий по сбору информации, внедрения вредоносных компьютерных программ (вирусов) и иных событий, приводящих к возникновению инцидентов;
• планирование и принятие мер по предотвращению повторного возникновения инцидентов.

Этими же документами закрывается ряд организационных мер, например РСБ.1 «Определение событий безопасности, подлежащих регистрации, и сроков их хранение» и РСБ.2 «Определение состава и содержания информации о событиях безопасности, подлежащих регистрации». Все эти вещи можно указать в инструкции по реагированию на инциденты, чтобы не плодить отдельные документы.

02-03 приказ о классификации и акт классификации

Классификация государственной информационной системы очень важный этап формирования требований к системе защиты информации. От того какой мы класс установим, будет зависеть и количество требований, которые нам нужно выполнить.

Приказом мы назначаем комиссию по классификации, а актом эта комиссия фиксирует параметры информационной системы и на основе исходных данных присваивает первый, второй или третий класс защищенности.

Единственное на что необходимо обратить внимание – если в ГИС обрабатываются, в том числе персональные данные, то для них тоже необходимо в этом же акте определить их уровень защищенности.

03 инструкция пользователя

Основное правовое обоснование необходимости такой инструкции это все места в законодательстве, где сказано про инструктаж пользователей по вопросам информационной безопасности. Например, часть 1 статьи 18.1 закона «О персональных данных»:

6) ознакомление работников оператора, непосредственно осуществляющих обработку персональных данных, с положениями законодательства Российской Федерации о персональных данных, в том числе требованиями к защите персональных данных, документами, определяющими политику оператора в отношении обработки персональных данных, локальными актами по вопросам обработки персональных данных, и (или) обучение указанных работников.

Косвенная необходимость такого документа – юридическое оформление ответственности пользователей за возможные инциденты информационной безопасности. Как

, в случаях когда таких инструкций не существует и (или) пользователь с ней не ознакомлен, пользователь, нарушивший требования ИБ скорее всего не будет привлечен к ответственности.

Что касается самого документа, здесь мы решили не грузить пользователей не нужной им ерундой, сделать документ не слишком сложным для восприятия и полезным не только в отношении ИБ на предприятии, но и в вопросах ИБ в личной жизни. Например, описали методы социальной инженерии с примерами.

03 приказ об утверждении перечня лиц

Нам необходимо определить, кто и к каким персональным данным имеет доступ. Если по доступу в информационные системы у нас уже разработан такой же документ в составе политики ИБ, то дублировать одно и то же здесь не требуется. Но нужно обратить внимание на то, что здесь помимо лиц, допущенных к автоматизированной обработке ПДн в автоматизированных системах необходимо указывать и тех, кто допущен к неавтоматизированной обработке ПДн (например, к бумажным папкам с личными делами сотрудников). Здесь так же, как и в политике ИБ регуляторы хотят видеть именно пофамильные списки.

04 политика в отношении обработки персональных данных

Не путать с политикой ИБ! Тут можно резонно спросить: «А зачем нам еще одна политика?».

Часть 2 статьи 18.1 Федерального закона «О персональных данных»:

Оператор обязан опубликовать или иным образом обеспечить неограниченный доступ к документу, определяющему его политику в отношении обработки персональных данных, к сведениям о реализуемых требованиях к защите персональных данных. Оператор, осуществляющий сбор персональных данных с использованием информационно-телекоммуникационных сетей, обязан опубликовать в соответствующей информационно-телекоммуникационной сети документ, определяющий его политику в отношении обработки персональных данных, и сведения о реализуемых требованиях к защите персональных данных, а также обеспечить возможность доступа к указанному документу с использованием средств соответствующей информационно-телекоммуникационной сети.

Итак, это документ, который должен быть разработан и должен быть опубликован для всех желающих. Но мы не хотим особо много рассказывать о принимаемых мерах по защите персональных данных, поэтому для выполнения требований законодательства создаем отдельный документ, где максимально абстрактно описываем все, что только можно абстрактно описать.

04 приказ о вводе в действие

В соответствии с 17-м приказом ФСТЭК, государственная (или муниципальная) информационная система может быть введена в действие только на основании аттестата соответствия требованиям по безопасности информации.

05 политика информационной безопасности

Наверное, один из наиболее объемных документов из всего набора. Помните выше мы писали о документе «Меры защиты информации в ГИС» и про большое количество «правил и процедур», которые необходимо прописать в ОРД? Собственно «Политика ИБ» это и есть, по сути, сборник всех таких правил и процедур.

Тут, пожалуй, стоит остановиться на слове «Политика». Нам часто говорят, что у нас «Политика» слишком целенаправленная, а на самом деле документ с таким названием должен быть более абстрактным и высокоуровневым. Может и так, но у нас как у безопасников все-таки в первую очередь с техническим бэкграундом слово «Политика» ассоциируется, например, с групповыми политиками домена, что уже в свою очередь ассоциируется с конкретными правилами и настройками.

На самом деле, как будет называться такой документ – не важно. Если не нравится слово «Политика» можно переименовать в «Правила и процедуры информационной безопасности». Это не главное. Главное, что в этом документе должны быть уже четко и конкретно прописаны эти самые правила и процедуры.

Здесь остановимся немного поподробнее.

Если открыть документ и начать с ним работать, можно заметить, что в некоторых местах нет конкретных заготовок текста, а вместо этого стоит сухое «Описать». Это потому, что некоторые вещи нельзя описать так, чтобы текст подходил одновременно хотя бы для половины конкретных информационных систем.

По основному тексту должно быть в целом все понятно, хотелось бы немного остановиться на приложениях.

Заявка на внесение изменений в списки пользователей

Многим кажется такая процедура отслеживания пользователей и их полномочий в системе сильно бюрократизированной, однако мы часто встречались с ситуациями, когда именно такой подход помогал продвинуться в расследовании инцидентов информационной безопасности.

В любом случае – делать такую процедуру регистрации пользователей или нет, решать каждому оператору самостоятельно. Здесь, наверное, сразу стоит оговориться, что явно делать именно так, как описано в нашем образце политики ИБ не требуется каким-либо законодательным актом.

Положение о разграничении прав доступа и перечень лиц

Разграничение прав доступа пользователей – мера очевидная для любого системного администратора. Дополнительно ее необходимость подкреплена мерами из приказов ФСТЭК: УПД.2 «Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа», УПД.

Поскольку в подавляющем количестве случаев оптимально использовать именно ролевую модель разграничения доступа, то и указанные приложения к политике ИБ заточены именно под этот случай.

Перечень лиц. Нас часто спрашивают, можно ли указывать здесь не конкретных людей, а должности. Особенно часто этот вопрос звучит от представителей больших организаций с большой текучкой кадров. Наш ответ – можете попробовать, но любой регулятор вам расскажет о принципе «персональной ответственности» и о том, что «главного бухгалтера» наказать нельзя, а «Марью Ивановну» можно.

Список разрешающих правил взаимодействия с внешними сетями

Правила создаются в основном во исполнение меры УПД.3 «Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами».

Поскольку, как уже было сказано, шаблоны заточены под самый депрессивный вариант, здесь тоже часто таблица заполняется «белыми списками». Но можно вписывать любые другие правила, если «белые списки» не обусловлены каким-нибудь особым требованием законодательства. Форма таблицы тоже примерная, можно переделывать под своё видение как угодно.

Список разрешенного программного обеспечения

Список создается во исполнение меры ОПС.3 «Установка (инсталляция) только разрешенного к использованию программного обеспечения и (или) его компонентов». Соответственно, чтобы знать какое ПО у нас в системе разрешено, должен быть утвержден список.

Часто список применяется для того чтобы понять, не установил ли пользователь что-нибудь ненужное себе на рабочий компьютер. Хотя по-хорошему саму возможность что-то самостоятельно устанавливать рядовым пользователям нужно устранять.

Далее идут списки ПО и пользователей для удаленного доступа. Заполняются, если есть такой доступ и да, это тоже требования ФСТЭК.

Порядок резервирования

Здесь даже наверное требования ФСТЭК приводить не нужно. Все понимают важность бэкапов и все помнят поговорку «есть 2 типа сисадминов: те, которые делают бэкапы и те, которые будут делать бэкапы». Однако на практике при аудите информационных систем часто случается такое, что админы говорят, что бэкапы у них точно делаются, но вопросы «что именно, куда именно и как часто бэкапится» остаются без ответа.

Актуальная таблица из приложения 10 к политике ИБ поможет избежать таких ситуаций.

Что касается требований по резервированию (хотя на самом деле требования больше относятся к восстановлению), то их тоже немало. Например, часть 2 статьи 19 федерального закона «О персональных данных»:

Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

Или требование от ФСТЭК:

ОДТ.4 Периодическое резервное копирование информации на резервные машинные носители информацииПлан обеспечения непрерывности функционирования информационной системы

Здесь мы постарались собрать заготовку различных вариантов факапов нештатных ситуаций и вариантов реагирования на них. Естественно, это примерный список, ненужное можно убирать, нужное добавлять.

Требование ФСТЭК, которое этим планом мы частично выполняем:

ОДТ.3 Контроль безотказного функционирования технических средств, обнаружение и локализация отказов функционирования, принятие мер по восстановлению отказавших средств и их тестирование

05-06 приказ об определении уровня защищенности персональных данных и соответствующий акт

Здесь все то же самое, что и с классификацией ГИС. Важно: если речи идет о ГИС с персональными данными, то эти два документа не нужны, так как определение уровня защищенности ПДн уже входит в акт классификации ГИС. На самом порядке определения уровня защищенности ПДн останавливаться не будем, на эту тему уже и так много написано.

06 приказ о контролируемой зоне и положение о контролируемой зоне

Необходимость этих документов обусловлена требованием ФСТЭК: ЗТС.2 «Организация контролируемой зоны, в пределах которой постоянно размещаются стационарные технические средства, обрабатывающие информацию, и средства защиты информации, а также средства обеспечения функционирования».

Здесь мы часто встречаемся с заблуждением, что контролируемой зоной можно считать только те помещения, которые оборудованы системами СКУД, видеонаблюдением и т. д., но это не так. Контролируемая зона, это территория, на которой исключается несанкционированный доступ к элементам информационной системы посторонними лицами.

07 план мероприятий по обеспечению безопасности…

План мероприятий можно разбить на 2 части – список разовых мероприятий по ИБ и список периодических мероприятий. Раз есть 2 части, то есть и две основные цели.

Нам часто задают такой вопрос: «А вот мы бедная государственная организация, требований по ИБ много, денег на их выполнение нет, а на носу проверка, что нам делать?». Ну, если совсем все плохо – то хотя бы составить план мероприятий. Так можно показать проверяющим, что вы в курсе о том, какие шаги вам нужно предпринять, но по какой-то причине ещё не. Это о разовых мероприятиях.

Вторая часть – периодические мероприятия, это выполнение ряда требований по постоянному внутреннему контролю информационной безопасности. Например, часть 1 статьи 18.1 закона «О персональных данных»:

1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:

4) осуществление внутреннего контроля и (или) аудита соответствия обработки персональных данных настоящему Федеральному закону и принятым в соответствии с ним нормативным правовым актам, требованиям к защите персональных данных, политике оператора в отношении обработки персональных данных, локальным актам оператора;

07 правила обработки пдн без использования средств автоматизации

Так почему-то исторически сложилось, что в вопросах защиты персональных данных много внимания уделяется этому относительно информационных систем и часто операторы забывают, что есть еще требования и по защите ПДн, обрабатываемых без использования средств автоматизации.

Такой обработке ПДн посвящено целое постановление Правительства РФ. Рассматриваемый внутренний документ как раз призван выполнить требования этого постановления. Тут главное — внимательно смотреть какие положения относятся к реальной ситуации, а какие – нет.

Здесь есть еще один важный момент, который нужно прояснить. Многих могут ввести в ступор следующие положения рассматриваемого здесь постановления Правительства:

1. Обработка персональных данных, содержащихся в информационной системе персональных данных либо извлеченных из такой системы (далее — персональные данные), считается осуществленной без использования средств автоматизации (неавтоматизированной), если такие действия с персональными данными, как использование, уточнение, распространение, уничтожение персональных данных в отношении каждого из субъектов персональных данных, осуществляются при непосредственном участии человека.

2. Обработка персональных данных не может быть признана осуществляемой с использованием средств автоматизации только на том основании, что персональные данные содержатся в информационной системе персональных данных либо были извлечены из нее.

Может сложиться впечатление, что во многих случаях обработка ПДн в том числе в информационных системах должна считаться неавтоматизированной. Но эту странность пофиксили введением в закон «О персональных данных» следующего определения:

4) автоматизированная обработка персональных данных — обработка персональных данных с помощью средств вычислительной техники;

Постановление Правительство не может противоречить Федеральному закону. В итоге, неавтоматизированная обработка ПДн – все, что вне информационных систем (в основном – бумажные носители).

08-14 журналы…

Журналы 08-10 это журналы учета носителей информации. По ФСТЭКу есть три вида таких носителей:

• жесткие диски в стационарных компьютерах, серверах, моноблоках и т. д.;
• носители информации в различных портативных устройствах (ноутбуки, нетбуки, планшеты, фотоаппараты и т. д.);
• съемные машинные носители (флешки, съемные HDD, карты памяти).

Мы очень хотели не плодить разные журналы и сделать один универсальный для учета всех возможных носителей информации. Но у разных типов носителей есть разные параметры. Например, у портативных устройств необходимо отмечать возможность использования устройства за пределами контролируемой зоны.

Остальные журналы появились скорее не из прямых требований, а по косвенным причинам. У нас есть план периодических мероприятий и проверяющие хотят видеть отметки о каждом проведенном мероприятии. Так появились и остальные журналы.

И последнее, что хотелось бы сказать о журналах. Мы посчитали важным добавить в каждый журнал инструкцию по его заполнению. Буквально по каждому столбцу описать, что туда вписывать, иногда даже с примерами. Это на самом деле избавило нас от огромного количества одинаковых вопросов по заполнению.

09 приказ об утверждении мест хранения пдн

Еще один документ по неавтоматизированной обработке. Здесь нужно определить места хранения тех же личных дел сотрудников в бумажном виде и ответственного за это место хранения. Местом хранения может быть шкаф, сейф, стеллаж и т. д.

Список сокращений

АС – автоматизированная система.

ИБ – информационная безопасность.

Информация – в документе: информация, подлежащая защите, представленная в виде электронных документов или иных совокупностей данных, хранящаяся на электронных носителях и/или циркулирующая в сетях передачи данных организации.

ЛВС – локальная вычислительная сеть.

НСД – несанкционированный доступ к информации.

ОС – операционная система.

ОТСС – основные технические средства и системы.

РС – рабочая станция, компьютер.

СВТ – средство вычислительной техники.

СЗИ – средства защиты информации.

СУБД – система управления базами данных.

10 форма согласия субъекта на обработку его пдн

Для случаев, когда с субъектов ПДн необходимо получать согласие в письменной форме. Здесь при изменении шаблона главное помнить, что содержание письменного согласия на обработку ПДн строго регламентировано частью 4 статьи 9 Федерального закона «О персональных данных».

12 форма соглашения о неразглашении персональных данных

Подписывают наши сотрудники, допущенные к обработке ПДн (как к автоматизированной, так и неавтоматизированной).

13 журнал учета обращений граждан

Работает в связке с правилами рассмотрения запросов субъектов ПДн. Все поступающие запросы регистрируем – здесь. Проверяющие требуют наличие журнала, даже если не было ни одного запроса.

Общие положения

2.1. Настоящее положение разработано на основе «Политики информационной безопасности».

2.2. Положение определяет основные задачи, функции, обязанности, права и ответственность Администратора информационной безопасности автоматизированной системы (далее – администратор ИБ).

2.3. Администратор информационной безопасности назначается приказом и является лицом, выполняющим функции по защите информации обрабатываемой, передаваемой и хранимой при помощи средств вычислительной техники в пределах зоны своей ответственности.

2.4. В своей деятельности Администратор ИБ руководствуется требованиями действующих федеральных законов, общегосударственных и ведомственных нормативных документов по вопросам защиты информации и контролирует их выполнение администраторами локальной вычислительной сети (далее – ЛВС), администраторами систем управления базами данных (далее – СУБД) и пользователями автоматизированной системы (далее – АС).

2.5. Настоящее Положение является дополнением к действующим нормативным документам по вопросам защиты информации и не исключает обязательного выполнения их требований.

Обязанности Администратора информационной безопасности

4.1 Для реализации поставленных задач и возложенных функций Администратор ИБ ОБЯЗАН:

4.1.1 Сопровождать СЗИ от НСД и ОТСС:

4.1.1.1 Вести учет и знать перечень установленных в подразделениях ОТСС, СЗИ от НСД и перечень задач, решаемых с их использованием.

4.1.1.2 Осуществлять непосредственное управление режимами работы и административную поддержку функционирования (настройку и сопровождение) применяемых на рабочих станциях (далее – РС) специальных программных и программно-аппаратных СЗИ от НСД.

4.1.1.3 Присутствовать при внесении изменений в конфигурацию (модификации) аппаратно-программных средств, защищенных РС и серверов, осуществлять проверку работоспособности системы защиты после установки (обновления) программных средств АС.

4.1.1.4 Периодически проверять состояние используемых СЗИ от НСД, осуществлять проверку правильности их настройки (выборочное тестирование).

4.1.1.5 Контролировать комплектность средств вычислительной техники (далее – СВТ) и изменения аппаратно-программной конфигурации.

4.1.1.6 Периодически – не реже 1 раза в год контролировать целостность печатей (пломб, наклеек) на устройствах, защищенных РС, где таковые печати (пломбы, наклейки) имеются.

4.1.1.7 Вести журнал учета нештатных ситуаций, фактов вскрытия и опечатывания, защищенных СВТ, выполнения профилактических работ, установки и модификации аппаратных и программных СЗИ.

4.1.1.8 Проводить периодический инструктаж сотрудников подразделения (пользователей АС) по правилам работы с используемыми СЗИ.

4.1.2 Организовывать разграничения доступа:

4.1.2.1 Знать перечень защищаемых информационных ресурсов и участвовать в разработке системы их защиты.

4.1.2.2 Разрабатывать совместно с администраторами АС решения по:

• составу доменов сети, системы доверительных отношений между ними;
• составу групп (локальных и глобальных) каждого домена;
• приписке пользователей с одинаковыми требованиями, статусом безопасности и характером решаемых задач к соответствующим группам;
• определению информационных связей между сегментами сети и требований к изоляции сегментов с использованием средств аппаратной безопасности сегментов;
• определению списка устройств, логических дисков, каталогов общего пользования на серверах с указанием состава допущенных к ним пользователей и режимом допуска;
• осуществлению контроля использования разделяемых ресурсов, процессом печати на общих принтерах;
• разработке порядка пользования электронной почты (использованию СЗИ при передаче закрытых документов);
• разработке порядка выхода пользователей в Сети общего пользования (далее – Сети) и использованию встроенных СЗИ от НСД в сервисных программах;
• определению режимов использования СЗИ: защита паролей, защита в протоколах передачи данных, кодирование файлов, подтверждение подлинности электронных документов (электронная подпись), подключение дополнительных алгоритмов криптографической защиты;
• разработке политики аудита: определение состава регистрируемых событий и списка лиц, имеющих допуск к журналам аудита.

4.1.2.3 Осуществлять учет и периодический контроль состава и полномочий пользователей различных РСАС.

4.1.2.4 Контролировать и требовать соблюдение установленных правил по организации парольной защиты в АС.

4.1.2.5 Осуществлять оперативный контроль работы пользователей, защищенных РС, анализировать содержимое журналов событий операционных систем (далее — ОС) и СЗИ от НСД этих РС, адекватно реагировать на возникающие нештатные ситуации.

4.1.2.6 Принимать участие в работах по внесению изменений в аппаратно-программную конфигурацию серверов и РСАС. Контролировать соблюдение сотрудниками подразделений автоматизации утвержденного порядка проведения работ по установке и модернизации аппаратных и программных средств РС и серверов.

4.1.2.7 Контролировать выполнение требований по обеспечению безопасности информации при организации технического обслуживания РС и отправке их в ремонт (контролировать стирание информации на магнитных носителях).

4.1.2.8 Организовывать учет, хранение, прием и выдачу персональных идентификаторов и ключевых дискет ответственным исполнителям, осуществлять контроль правильности их использования.

4.1.2.9 Осуществлять периодический контроль порядка учета, создания, хранения и использования резервных и архивных копий массивов данных.

4.1.2.10 По указанию руководства своевременно и точно отражать изменения в организационно-распорядительных и нормативных документах по управлению СЗИ от НСД, установленных на РСАС.

4.1.2.11 Требовать от пользователей стирания остаточной информации на несъёмных носителях (жестких дисках) установленным порядком, а в оперативной памяти по окончании обработки информации путем перезагрузки РС.

4.1.2.12 Контролировать обеспечение защиты конфиденциальной информации при взаимодействии абонентов с информационными сетями общего пользования.

4.1.3 Контролировать эффективность защиты информации:

4.1.3.1 Проводить работу по выявлению возможности вмешательства в процесс функционирования АС и осуществления НСД к информации и техническим средствам РС.

4.1.3.2 Докладывать руководству о выявленных угрозах безопасности информации, обрабатываемой в АС, об имевших место попытках НСД к информации и техническим средствам РС.

4.1.3.3 Проводить занятия с администраторами и пользователями АС по правилам работы на РС, оснащенных СЗИНСД, и по изучению руководящих документов по вопросам обеспечения безопасности информации с разбором недостатков, выявленных при контроле эффективности защиты информации.

4.1.3.4 Участвовать в расследовании причин совершения нарушений и возникновения серьезных кризисных ситуаций в АС.

4.2 Администратору ИБ ЗАПРЕЩАЕТСЯ:

4.2.1 Используя служебное положение, создавать ложные информационные сообщения и учетные записи пользователей, получать доступ к информации и предоставлять его другим с целью ее модификации, копирования, уничтожения, блокирования доступа к информации;

4.2.2 Самостоятельно (без согласования с подразделением автоматизации) вносить изменения в настройки серверной части АС;

4.2.3 Использовать в своих и в чьих-либо личных интересах ресурсы АС, предоставлять такую возможность другим;

4.2.4 Выключать СЗИ от НСД без санкции руководства;

4.2.5 Передавать третьим лицам тем или иным способом сетевые адреса, имена, пароли, информацию о привилегиях пользователей, конфигурационные настройки, другую информацию о структуре, составе, программном и техническом обеспечении и особенностях функционирования и защиты АС;

4.2.6 Производить в рабочее время без санкции руководства и предупреждения пользователей действия, приводящие к сбою, остановке, замедлению работы АС, блокированию доступа, потере информации;

4.2.7 Нарушать правила эксплуатации оборудования АС;

4.2.8 Корректировать, удалять, подменять журналы аудита.

Права и ответственность Администратора информационной безопасности

5.1. Администратор ИБ имеет право:

5.1.1. Анализировать права доступа к ресурсам на серверах АС и РС пользователей.

5.1.2. Требовать от администраторов и пользователей АС выполнения инструкций по обеспечению безопасности и защите информации в АС.

5.1.3. Участвовать в служебных расследованиях по фактам нарушения установленных требований обеспечения информационной безопасности, НСД, утраты, порчи защищаемой информации и технических компонентов АС.

5.1.4. Осуществлять оперативное вмешательство в работу пользователя при явной угрозе безопасности информации в результате несоблюдения установленной технологии обработки информации и невыполнения требований по безопасности с последующим докладом руководству.

5.1.5. Производить анализ защищенности АС путем применения специального ПО, осуществления попыток взлома системы защиты АС. Такие работы должны проводиться в часы наименьшей информационной нагрузки с обязательным согласованием с начальником управления автоматизации.

5.1.6. Вносить свои предложения по совершенствованию мер защиты в АС.

5.2. Администратор ИБ несет ответственность за:

5.2.1. Реализацию принятой политики информационной безопасности;

5.2.2. Программно-технические и криптографические СЗИ, а также за качество проводимых им работ по обеспечению защиты информации в соответствии с функциональными обязанностями.

Комплектность документов

Если опираться на законодательство по защите информации, то там мало где сказано — какие конкретно документы мы должны разрабатывать, поэтому приходится опираться на различные косвенные намеки.

Для примера приведем часть 2 статьи 19 закона №152-ФЗ «О персональных данных». Обычным текстом будет текст закона, курсивом – примечания автора.

Пара уточнений

Для начала, чтобы исключить лишние вопросы и домыслы считаем необходимым прояснить несколько моментов.

1. В статье мы рассмотрим только внутренние организационно-распорядительные документы (далее – ОРД) по защите информации. Проектные, аттестационные и прочие документы рассматриваться не будут.
2. Модель угроз тоже рассматривать не будем, хотя ее шаблон и есть здесь. Разработка модели угроз это отдельная история. Напишите в комментариях – нужен ли на Хабре мануал по разработке модели угроз?
3. В статье будем опираться на наш комплект шаблонов. Он не является каким-то стандартом или общепринятым набором. В этом комплекте отражен сугубо наш подход к разработке ОРД. Поскольку законодательство зачастую не предписывает в этом плане ничего конкретного, у вас может быть свое мнение насчет комплектности и содержания документов и это нормально!
4. В шаблонах могут быть ошибки и опечатки. Мы сами постоянно улучшаем и дорабатываем их.
5. В контексте выполнения требований будет затронута в основном тематика персональных данных (152-ФЗ и подзаконные акты) и государственных информационных систем (17 приказ ФСТЭК). Помимо этого есть еще отдельная история с финансовыми организациями (требования ЦБ РФ) и различные стандарты (ISO 2700х и другие) – их мы рассматривать здесь не будем.

Пару слов в защиту «бумажной» безопасности

Поскольку речь в статье пойдет о так называемой «бумажной» безопасности, хотелось бы сразу обозначить нашу позицию об этой части инфобеза.

У многих технарей, работающих «руками» зачастую вызывает резкое отторжение и пренебрежение эта самая «бумажная» безопасность. Однако, как это ни странно, когда такой технарь получает в свое распоряжению новую железку или софт (а иногда и то и другое в одном продукте), он хочет в первую очередь ознакомиться с документацией на это чудо техники.

Самое частое обоснование такой пренебрежительной позиции – эти все документы делаются просто для галочки, чтобы выполнить требования законодательства, это пустая трата времени, документы нужно поддерживать, но никто заниматься этим не будет и т. д. и т. п.

К сожалению, такая позиция не беспочвенна. За многие годы как среди безопасников на местах, так и среди лицензиатов, интеграторов и прочих заинтересованных лиц сложилась печальная практика такого же отношения к документам по информационной безопасности.

Отчасти это еще усугубляется тем, что зачастую документы по информационной безопасности пишут люди, далекие от информационных технологий. Ведь как можно писать раздел про защиту средств виртуализации, не понимая как эта самая виртуализация работает?

Чтобы такую ситуацию переломить, необходимо делать хорошие, содержательные и полезные документы. В то же время эти документы должны удовлетворять действующему законодательству по защите информации. Давайте посмотрим, что же можно со всем этим сделать.

Работа администратором информационной безопасности в москве, свежие вакансии администратором информационной безопасности на superjob

§

Заключение

Надеемся, что этот

небольшой

гайд по внутренней документации по информационной безопасности будет полезен. Возможно, написано несколько сумбурно, так как тема действительно обширная, а растягивать тему на несколько частей не хотелось. Если мы что-то упустили и есть вопросы по теме, ответим на них в комментариях.