Структура инструкции по защите информации в организации

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

1. Раздел «Общее» — документы, утверждение которых, как правило необходимо для любой системы, независимо от ее классификации:

• Приказ о назначении ответственного за организацию обработки персональных данных и администратора безопасности информации
• Инструкция администратора безопасности
• Инструкция ответственного за организацию обработки персональных данных
• Приказ о назначении группы реагирования на инциденты информационной безопасности и о правилах регистрации инцидентов информационной безопасности и реагирования на них
• Инструкция по реагированию на инциденты информационной безопасности
• Инструкция пользователя государственной информационной системы
• Приказ об утверждении внутренних нормативных актов по защите информации
• Политика информационной безопасности в составе:
• — Общие положения
• — Технологические процессы обработки защищаемой информации в информационных системах
• — Правила и процедуры идентификации и аутентификации пользователей, политика разграничения доступа к ресурсам информационной системы
• — Правила и процедуры управления установкой (инсталляцией) компонентов программного обеспечения
• — Правила и процедуры обеспечения доверенной загрузки средств вычислительной техники
• — Правила и процедуры выявления, анализа и устранения уязвимостей
• — Правила и процедуры контроля состава технических средств, программного обеспечения и средств защиты информации
• — Правила и процедуры резервирования технических средств, программного обеспечения, баз данных, средств защиты информации и их восстановления при возникновении нештатных ситуаций
• — Форма заявки на внесение изменений в списки пользователей и наделение пользователей полномочиями доступа к ресурсам информационной системы
• — Форма задания на внесение изменений в списки пользователей информационной системы
• — Форма положения о разграничении прав доступа (ролевая система допуска к ресурсам)
• — Форма перечня лиц, должностей, служб и процессов, допущенных к работе с ресурсами информационной системы
• — Форма перечня помещений, в которых разрешена работа с ресурсами информационной системы, в которых размещены технические средства, а также перечень лиц, допущенных в эти помещения
• — Форма списка разрешающих правил взаимодействия с внешними телекоммуникационными сетями
• — Форма списка разрешенного программного обеспечения в информационной системе
• — Форма списка прикладного программного обеспечения информационной системы, доступного внешним пользователям
• — Форма списка пользователей, которым в соответствии с должностными обязанностями предоставлен удаленный доступ к информационной системе
• — Порядок резервирования информационных ресурсов
• — План обеспечения непрерывности функционирования информационной системы
• Приказ об организации контролируемой зоны
• Положение о контролируемой зоне
• План мероприятий по обеспечению безопасности защищаемой информации, выполнению требований законодательства по защите информации, а также по контролю уровня защищенности и выполнения мер по защите информации в информационной системе
• Форма журнала учета машинных носителей информации, стационарно устанавливаемых в корпус средств вычислительной техники
• Форма журнала учета портативных вычислительных устройств, имеющих встроенные носители информации
• Форма журнала учета приема/выдачи съемных машинных носителей информации
• Форма журнала учета средств защиты информации
• Форма журнала учета периодического тестирования средств защиты информации
• Форма журнала проведения инструктажей по информационной безопасности
• Форма журнала учета мероприятий по контролю обеспечения защиты информации

2. Раздел «Только ГИС» — небольшая подборка документов, которые необходимы для государственных или муниципальных информационных систем:

• Приказ о необходимости защиты информации, содержащейся в государственной информационной системе
• Приказ о необходимости защиты информации, содержащейся в муниципальной информационной системе
• Приказ о классификации государственной информационной системы
• Форма акта классификации государственной информационной системы
• Приказ о вводе в эксплуатация государственной информационной системы

3. Раздел «ПДн» — документы по защите персональных данных, регламентированные 152-ФЗ и подзаконными актами:

• Положение о защите и обработке персональных данных в составе:
• — Общие положения
• — Основные понятия и состав персональных данных
• — Общие принципы обработки персональных данных
• — Порядок сбора и хранения персональных данных
• — Процедура получения персональных данных
• — Передача персональных данных третьим лицам
• — Трансграничная передача персональных данных
• — Порядок уничтожения и блокирования персональных данных
• — Защита персональных данных
• — Согласие на обработку персональных данных
• — Организация доступа работников к персональным данным субъектов
• — Организация доступа субъекту персональных данных к его персональным данным
• — Права и обязанности оператора персональных данных
• — Права и обязанности работников, допущенных к обработке персональных данных
• — Права субъекта персональных данных
• — Ответственность за нарушение норм, регулирующих обработку и защиту персональных данных
• Правила рассмотрения запросов субъектов персональных данных или их представителей
• Приказ об утверждении перечня лиц, допущенных к обработке персональных данных
• Форма перечня лиц, допущенных к обработке персональных данных
• Политика в отношении обработки персональных данных
• Приказ об определении уровня защищенности персональных данных
• Форма акта определения уровня защищенности персональных данных
• Правила обработки персональных данных без использования средств автоматизации
• Приказ о назначении комиссии по уничтожению документов, содержащих персональные данные
• Форма акта уничтожения персональных данных
• Приказ об утверждении мест хранения персональных данных и лицах, ответственных за соблюдение конфиденциальности персональных данных при их хранении
• Форма согласия субъекта на обработку его персональных данных
• Положение о системе видеонаблюдения
• Форма соглашения о неразглашении персональных данных
• Форма журнала учета обращений граждан-субъектов персональных данных о выполнении их законных прав

4. Раздел «СКЗИ» — документы, необходимые при использовании в системе защиты информации криптографических средств

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

5. Модель угроз безопасности информации

Гайд по внутренней документации по информационной безопасности. Что, как и зачем

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных; (нужна модель угроз)

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

3) применением прошедших в установленном порядке процедуру оценки соответствия средств защиты информации;

4) оценкой эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных;

5) учетом машинных носителей персональных данных; (очевидно нужен некий журнал учета и разработанные правила учета машинных носителей)

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

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

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

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

Данным примером нам хотелось показать разницу: как написан закон и что по факту он от нас требует. Здесь мы не видим прямого требования «оператор должен разработать модель угроз», но эта необходимость все равно следует из текста 152-ФЗ, так как выполнение любого требования подтверждается документально.

Более конкретно о комплектности и содержании ОРД нам говорит ФСТЭК. В 2014 году этот регулятор выпустил методический документ «Меры защиты информации в государственных информационных системах». Документ без сарказма отличный, если вам было что-то непонятно по порядку выполнения мер 17-го, 21-го или другого приказа ФСТЭК (да, хоть документ и предназначен для ГИС, но меры по большей части у ФСТЭКа совпадают), обратитесь к этому документу, возможно, станет сильно понятнее.

Так вот, в этом документе ФСТЭК более расширенно расписывает меры по обеспечению безопасности информации и очень часто можно встретить такой текст:

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

Правила и процедуры управления учетными записями пользователей регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.1)

Правила и процедуры управления информационными потоками регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.3)

Отлично, уже что-то, но этих правил и процедур целый вагон.

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

Главная мысль этого раздела – есть гора требований в законодательстве по защите информации, выполнение многих из них нужно подтвердить документально. Делать ли под каждое требование отдельный документ или слить все в одну большую «Политику ИБ» — решать каждому. Все дополнительное, что нам нужно в документах прописать не по требованиям, а исходя из практической необходимости, дописываем без каких-либо проблем.

Кстати, обратите внимание, что в таблице и в самих документах некоторые разделы или абзацы помечены «К1» или «К2+». Это означает что раздел или абзац необходим только для информационных систем 2 класса и выше или для первого (максимального класса). Все что не помечено – выполняется во всех государственных информационных системах и ИСПДн.

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

Наши шаблоны разбиты на 4 папки:

Общее – документы, которые необходимо разработать для всех систем (по мере применимости), будь то ИСПДн, ГИС, АСУ ТП или объект КИИ.

Только ГИС – документы для государственных информационных систем или муниципальных информационных систем, тут только уникальные документы, нужные для ГИС и МИС.

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

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

Рассмотрим далее подробнее документы, откуда они появились и какие требования выполняют.

Общие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Разграничение прав доступа пользователей – мера очевидная для любого системного администратора. Дополнительно ее необходимость подкреплена мерами из приказов ФСТЭК: УПД.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 года), мы постарались как-то сбалансировать внутренние документы, чтобы и вам и нам, как говорится. Но проверяющие от ФСБ у нас ребята самые непредсказуемые, поэтому эти документы у нас часто дополняются и изменяются.

Заключение

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

небольшой

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

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

Чтобы защитить себя в этой области, организациям уже сейчас стоит подумать, какие средства выбрать для защиты и каких атак стоит опасаться больше всего. Об этом рассказал Андрей Голов, генеральный директор «Кода Безопасности».

Содержание:

• Что такое «информационная безопасность предприятия»?
• Как осуществить контроль информационной безопасности?
• Виды угроз информационной безопасности
• Средства защиты информации
• Обеспечение информационной безопасности предприятий
• Этапы внедрения системы безопасности
• Организационные меры
• Режим коммерческой тайны
• Технические меры
• Итог: как выбрать комплекс мер по информационной безопасности в организации?

Что такое «информационная безопасность предприятия»?

Если говорить просто, то это комплекс мер, которые закрывают три ключевых уровня:

1. Работоспособность некритичных для бизнеса сервисов — например, сайта компании. Компания должна быть готова к банальным DDoS-атакам и прочим киберсредствам нападения. 
2. Защита критической информации, к которой относятся персональные данные и коммерческие тайны. Задача ИБ-специалистов защитить ИТ-узлы, чтобы организация могла функционировать и при этом не нести репутационные или финансовые потери. 
3. Требования регуляторов. Часто, увидев смету на решения информационной безопасности, руководство компании пытается на них «забить». Государство понимает нежелание организаций тратить деньги на вещи, которые могут не случиться, но, с другой стороны, есть критические процессы, и их необходимо предупреждать, поэтому власти заставляют делать это законодательно. 

Три уровня — это минимум, под которым понимается система информационной безопасности организации. Более глобальный вопрос звучит так: кто атакует? 

Это могут быть: 

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

То, что эффективно против студентов, вряд ли остановит хакеров на службе у государства. Это мы увидели в феврале-марте 2022 года: уровень систем информационной безопасности организаций РФ оказался ниже необходимого из-за выросшего качества атак.

Компании это поняли, поэтому за последний год затраты на ИБ существенно выросли.

Как осуществить контроль информационной безопасности?

Есть несколько способов в организации защиты информационной безопасности: 

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

Виды угроз информационной безопасности

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

Среди них можно выделить: 

• вредоносное ПО (шифровальщики, вирусы, троянцы);
• SQL-инъекции (фишинг, DoS, перехват данных). 

Опасность атаки определяют по специальной модели угроз, которая состоит из нескольких параметров-вопросов: 

• Какими ресурсами располагают злоумышленники?
• Сколько времени они готовы потратить на атаку?

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

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

На сегодня отечественные разработчики создали десятки решений информационной безопасности, которые закрывают все сегменты ИТ-инфраструктуры. 

Они относятся:

• к контролю доступа, 
• защите данных и приложений, 
• обнаружению и реагированию на инциденты.

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

Сейчас особенно актуальными считаются межсетевые экраны следующего поколения (Next Generation Firewall, NGFW), которые сочетают несколько решений с единой панелью управления. Это особенно полезно для крупных ИТ-инфраструктур. 

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

В построении системы информационной безопасности организации средства защиты не занимают ведущую роль. 

Почему? Потому что сначала необходимо разобраться: а какие последствия в принципе критичны. 

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

Этапы внедрения системы безопасности

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

Затем анализ продолжается: 

• нужно обозначить те бизнес-процессы, в которых нарушения повлекут недопустимые последствия, 
• понять, какие ИТ-системы их поддерживают. 

Финальный этап — определение возможных инструментов защиты. 

К недопустимым последствиям относятся: 

1. Утечка данных пользователей;
2. Техногенные катастрофы;
3. Остановка обеспечения услуг компании. 

Организационные меры

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

Скажем, инструкция по работе с интернетом и жесткое требование: 

• не кликать по ссылкам в почте и мессенджерах; 
• менять пароль каждые полгода; 
• не использовать один и тот же пароль для разных сервисов. 

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

Режим коммерческой тайны

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

В основном она касается случаев, которые относятся к краже информации, но есть и второй момент. Как известно, слабое место ИБ — это человек, поэтому хакеры часто прибегают к социальному инжинирингу, и «точкой входа» может стать сотрудник компании, который даже не подозревает, что его используют. 

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

Технические меры

ИТ-инфраструктура предприятия в идеале напоминает подводную лодку — отсеки разделены переборками, которые задраиваются в случае проблемы и сохраняют судно на плаву. 

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

Итог: как выбрать комплекс мер по информационной безопасности в организации?

Информационная безопасность предприятия — это масштабная задача, успешность которой зависит от множества факторов. 

Компания должна понимать:

• Какие ИБ-события она не может допустить;
• Удар по каким бизнес-процессам станет критическим;
• Какие ИТ-системы поддерживают эти процессы. 

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

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

Фото на обложке сгенерировано с помощью нейросети Midjourney

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

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

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

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

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

Компании имеют право самостоятельно решать, какую информацию и как защищать, если не предусмотрены конкретные требования законодательства. Главная цель политики — предугадать все риски и создать эффективную систему противостояния им. 

Что такое формализация политики ИБ и зачем она нужна

Политика ИБ обычно формализуется, то есть предстает в виде четкого регламента. Правила «на словах» не работают, поскольку не являются утвержденными требованиями. 

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

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

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

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

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

Несостоявшиеся политики информационной безопасности компании

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

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

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

Какие положения включает политика информационной безопасности

Политика компании в области информационной безопасности включает следующие аспекты:

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

Важно, чтобы все положения политики были связаны между собой и не противоречили друг другу. 

Концепция защиты в рамках политики информационной безопасности компании

Важно различать понятия «концепция информационной безопасности» и «стратегия информационной безопасности»: первая не подлежит изменениям, а вторая является динамичной, то есть может дополняться.

Ключевые составляющие концепции информационной безопасности:

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

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

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

Требования к составлению регламентирующей документации 

При документировании политики информационной безопасности компании важно учитывать следующие нюансы:

• Не все сотрудники компании знают технические термины. Поэтому следует составлять регламент понятным и простым языком.
• Если политика будет слишком объемной, есть риск, что с ней не ознакомятся должным образом. Лучше формулировать коротко, но емко.

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

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

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

К внедрению политики следует приступать только тогда, когда документация полностью сформирована и согласована. Ниже приведена последовательность шагов по внедрению политики ИБ в компании:

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

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

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

Контроль соблюдения политики безопасности

К сожалению, некоторые сотрудники организаций не соблюдают требования политики информационной безопасности компании и совершают неправомерные или необдуманные действия, которые приводят к утечке данных. Чтобы выявить нарушения силами службы безопасности, потребуется достаточно много времени. Задачу упростят технические средства для мониторинга и предотвращения инцидентов — DLP-системы (Data Leak Prevention). Вот как они работают:

• Анализируют характер коммуникаций и поведение сотрудников, выявляют все виды контактов пользователей (личные, уникальные, рабочие).
• Формируют досье на сотрудников.
• Создают архив коммуникаций.
• Осуществляют мониторинг передачи конфиденциальной информации, проверяют все операции с конфиденциальными данными на предмет соответствия политикам.
• Блокируют передачу информации, если это нарушает политику безопасности.
• Визуализируют данные для формирования отчетности и проведения расследований инцидентов.

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

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

Заключение

Политика информационной безопасности компании необходима для выстраивания системы защиты информационных активов от различных видов угроз и их нейтрализации. При разработке политики ИБ мы рекомендуем обращать не меньшее внимание на этапы ее внедрения в компании и контроль их соблюдения всеми сторонами (участниками). В этом помогут DLP-системы, которые отслеживают действия сотрудников и формируют доказательную базу для расследования инцидентов. 

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