какие документы должны быть в организации по информационной безопасности

Законодательство об информационной безопасности: 5 ФЗ о том, как хранить и защищать информацию

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

Мы собрали для вас пять основных ФЗ о защите информации и информационной безопасности и кратко рассказали их ключевые моменты.

149-ФЗ «Об информации, информационных технологиях и о защите информации»

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

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

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

152-ФЗ «О персональных данных»

Этот закон регулирует работу с персональными данными — личными данными конкретных людей. Его обязаны соблюдать те, кто собирает и хранит эти данные. Например, компании, которые ведут базу клиентов или сотрудников. Мы подробно рассматривали этот закон в отдельной статье «Как выполнить 152-ФЗ о защите персональных данных и что с вами будет, если его не соблюдать»

Ключевые моменты закона:

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

98-ФЗ «О коммерческой тайне»

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

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

63-ФЗ «Об электронной подписи»

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

Ключевые моменты закона:

187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»

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

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

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

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

Источник

Документы по информационной безопасности

Защита информации
с помощью DLP-системы

Законы, регулирующие порядок работы с конфиденциальной информацией

Федеральный закон «О защите персональных данных»

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

Федеральный закон «О коммерческой тайне»

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

Закон «Об архивном деле»

Федеральный закон «Об архивном деле». Этот закон регулирует отношения в сфере организации хранения, комплектования, учета и использования документов Архивного фонда Российской Федерации и других архивных документов независимо от их форм собственности.

Стандарт Банка России

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

Соглашение Basel II

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

Закон HIPAA

Health Insurance Portability and Accountability Act of 1996 гласит, что: «Все медицинские, страховые и финансовые организации, работающие с чувствительной медицинской информацией должны хранить не менее 6 лет всю свою электронную документацию».

Закон SOX

Sarbanes-Oxley Act of 2002, §802 – Все публичные компании, представленные на фондовом рынке США, обязаны собирать, архивировать и хранить на протяжении минимум семи лет электронную корпоративную корреспонденцию.

Правило 17а-4 Комиссии по ценным бумагам США

SEC Rule 17a-4. Все финансовые публичные компании, представленные на фондовом рынке США, должны хранить переписку с клиентами в виде отдельной базы данных.

Федеральный закон «О связи»

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

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

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

Доктрина ИБ РФ была утверждена президентом России В.В. Путиным 9.09.2000 года. Новую редакцию доктрины приняли в декабре 2016 года.

Федеральный закон «Об информации, информационных технологиях и о защите информации»

Закон «Об информации, информационных технологиях и защите информации» определяет и закрепляет права на защиту информации и информационную безопасность граждан и организаций в ЭВМ и в информационных системах, а также вопросы информационной безопасности граждан, организаций, общества и государства. В законе дано правовое определение понятия «информация»: «информация — сведения (сообщения, данные) независимо от формы их представления».

Федеральный закон «О противодействии неправомерному использованию инсайдерской информации»

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

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

Федеральный закон «О банках и банковской деятельности»

Безопасность информации, отнесенной к банковской тайне, обеспечивается в соответствии со статьей 26 Федерального закона «О банках и банковской деятельности»

Федеральный закон «Об электронной подписи»

В Законе РФ от 6 апреля 2011 года №63-ФЗ «Об электронной подписи» прописаны условия использования ЭП, особенности её использования в сферах государственного управления и в корпоративной информационной системе. Благодаря ЭП теперь, в частности, многие российские компании осуществляют свою торгово-закупочную деятельность в Интернете, через «Системы электронной торговли», обмениваясь с контрагентами необходимыми документами в электронном виде, подписанными ЭП. Это значительно упрощает и ускоряет проведение конкурсных торговых процедур.

ПОПРОБУЙТЕ «СЁРЧИНФОРМ КИБ»!

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

Источник

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

1. Введение

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

2. Основные понятия

Система − автоматизированная информационная система передачи и приема информации в электронном виде по телекоммуникационным каналам связи в виде юридически значимых электронных документов с использованием средств электронной подписи.
Автоматизированное рабочее место (АРМ) – ПЭВМ, с помощью которой пользователь осуществляет подключение для работы в Системе.

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

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

Сертификат соответствия − документ, выданный по правилам системы сертификации для подтверждения соответствия сертифицированной продукции установленным требованиям.

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

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

3. Риски использования электронной подписи

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

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

4. Общие принципы организации информационной безопасности в Системе

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

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

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

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

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

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

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

5. Требования и рекомендации по обеспечению информационной безопасности на рабочем месте пользователя

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

5.1 Персонал

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

К работе на АРМ с установленным СКЗИ допускаются только определенные для эксплуатации лица, прошедшие соответствующую подготовку и ознакомленные с пользовательской документацией на СКЗИ, а также другими нормативными документами по использованию электронной подписи.

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

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

Должностные инструкции пользователей АРМ и администратора безопасности должны учитывать требования настоящих Правил.

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

5.2 Размещение технических средств АРМ с установленным СКЗИ

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

Рекомендуется использовать АРМ с СКЗИ в однопользовательском режиме. В отдельных случаях, при необходимости использования АРМ несколькими лицами, эти лица должны обладать равными правами доступа к информации.

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

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

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

Рекомендуется определить в BIOS установки, исключающие возможность загрузки операционной системы, отличной от установленной на жестком диске: отключается возможность загрузки с гибкого диска, привода CD-ROM, исключаются прочие нестандартные виды загрузки ОС, включая сетевую загрузку.

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

5.3 Установка программного обеспечения на АРМ

На технических средствах АРМ с установленным СКЗИ необходимо использовать только лицензионное программное обеспечение фирм-изготовителей, полученное из доверенных источников.

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

Не допускается установка на АРМ средств разработки и отладки программного обеспечения. Если средства отладки приложений необходимы для технологических потребностей пользователя, то их использование должно быть санкционировано администратором безопасности. В любом случае запрещается использовать эти средства для просмотра и редактирования кода и памяти приложений, использующих СКЗИ. Необходимо исключить попадание в систему средств, позволяющих осуществлять несанкционированный доступ к системным ресурсам, а также программ, позволяющих, пользуясь ошибками ОС, получать привилегии администратора.

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

Рекомендуется установить и использовать на АРМ антивирусное программное обеспечение.

Необходимо регулярно отслеживать и устанавливать обновления безопасности для программного обеспечения АРМ (Service Packs, Hot fix и т п.), обновлять антивирусные базы.

5.4 Настройка операционной системы АРМ

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

Рекомендуется разработать и применить политику назначения и смены паролей (для входа в ОС, BIOS, при шифровании на пароле и т д.), использовать фильтры паролей в соответствии со следующими правилами:

5.5 Установка и настройка СКЗИ

Установка и настройка СКЗИ на АРМ должна выполняться в присутствии администратора, ответственного за работоспособность АРМ.

Установка СКЗИ на АРМ должна производиться только с дистрибутива, полученного по доверенному каналу.

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

При установке ПО СКЗИ на АРМ должен быть обеспечен контроль целостности и достоверность дистрибутива СКЗИ.

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

По завершении инициализации осуществляются настройка и контроль работоспособности ПО.

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

5.6 Подключение АРМ к сетям общего пользования

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

В случае подключения АРМ с установленным СКЗИ к общедоступным сетям передачи данных необходимо ограничить возможность открытия и исполнения файлов и скриптовых объектов (JavaScript, VBScript, ActiveX и т д.), полученных из сетей общего пользования, без проведения соответствующих проверок на предмет содержания в них программных закладок и вредоносных программ.

5.7 Обращение с ключевыми носителями

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

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

5.8 Обращение с ключевой информацией

Владелец сертификата ключа проверки ЭП обязан:

5.9 Учет и контроль

Действия, связанные с эксплуатацией СКЗИ, должны фиксироваться в «Журнале пользователя сети», который ведет лицо, ответственное за обеспечение информационной безопасности на АРМ. В журнал кроме этого записываются факты компрометации ключевых документов, нештатные ситуации, происходящие в системе и связанные с использованием СКЗИ, проведение регламентных работ, данные о полученных у администратора безопасности организации ключевых носителях, нештатных ситуациях, произошедших на АРМ, с установленным ПО СКЗИ.

В журнале может отражаться следующая информация:

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

В случае обнаружения «посторонних» (не зарегистрированных) программ, нарушения целостности программного обеспечения либо выявления факта повреждения печатей на системных блоках работа на АРМ должна быть прекращена. По данному факту должно быть проведено служебное расследование комиссией, назначенной руководителем организации, где произошло нарушение, и организованы работы по анализу и ликвидации негативных последствий данного нарушения.

Рекомендуется организовать на АРМ систему аудита в соответствии с политикой безопасности, принятой в организации, с регулярным анализом результатов аудита.

6. Заключение

Настоящие правила составлены на основе:

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 это журналы учета носителей информации. По ФСТЭКу есть три вида таких носителей:

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

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

Только ГИС

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 Журнал учета обращений граждан

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

Источник