Сведения о нормативном документе
 Скачать 0.61 Mb.
|
|
Cтр. 11 из 32 6.2.2.2. Должны документально фиксироваться результаты проведения кадровых проверок, а сами проверки при трудоустройстве следует проводить в соответствии с требованиями внутренних нормативных документов Компании. 6.2.2.3. Должны быть заключены со всеми работниками письменные соглашения, включающие в себя: • Обязательство о соблюдении требований Компании в области ИБ. • Обязательство о неразглашении сведений, составляющих коммерческую тайну Компании и персональные данные, ставшие известными сотрудникам во время работы. • Обязательство о недопущении возникновения конфликта интересов с работодателем. • Обязательство о приверженности корпоративным ценностям работодателя. Такие соглашения должны заключаться непосредственно при трудоустройстве в форме, регламентированной внутренними нормативными документами Компании. 6.2.2.4. Должны применяться дисциплинарные взыскания к сотрудникам, уличенным в нарушении требований ИБ или виновным в инцидентах ИБ. Такие дисциплинарные взыскания должны применяться в соответствии с установленными процедурами, а результаты применения таких взысканий следует фиксировать документально. 6.2.2.5. Должно осуществляться своевременное лишение прав доступа увольняемых сотрудников к информационным системам и сервисам Компании. Лишение прав доступа осуществляется работниками, отвечающими за управление доступом к информационным системам, на основании уведомления от подразделения, ответственного за управление персоналом. Такое уведомление должно подаваться своевременно, до момента увольнения работника, в форме и способом, установленными внутренними нормативными документами Компании. 6.2.2.6. Должен осуществляться учет технических средств, выдаваемых работникам или закрепляемых за ними. В число таких технических средств могут входить, в том числе, рабочие станции, ноутбуки, планшеты, мобильные телефоны и съемные носители информации. При увольнении работники должны сдать эти технические средства ответственным сотрудникам Компании (заведующему складом). 6.2.3 О БЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ ПРИ РАБОТЕ С МОБИЛЬНЫМИ УСТРОЙСТВАМИ , ИСПОЛЬЗУЕМЫМИ ДЛЯ ДОСТУПА К РЕСУРСАМ КОРПОРАТИВНОЙ СЕТИ , И НОСИТЕЛЯМИ ИНФОРМАЦИИ Использование мобильных устройств для доступа к ресурсам корпоративной сети увеличивает риски несанкционированного доступа и распространения конфиденциальной информации. Для снижения этих рисков, применение таких мобильных устройств должно осуществляться в строгом соответствии с установленными в Компании требованиями. 6.2.3.1. Должно быть реализовано предоставление доступа к мобильным устройствам исключительно после прохождения процедуры аутентификации. Способы аутентификации должны соответствовать принятым в Компании, в том числе, если для аутентификации применяются пароли – они должны соответствовать требованиям парольной политики Компании. 6.2.3.2. Должно применяться на планшетах и мобильных телефонах специализированное программное обеспечение, обладающее функционалом удаленного уничтожения информации. 6.2.3.3. Должны быть доведены до персонала процедуры, регламентирующие действия работников в случае утери мобильных устройств, на которых хранится или может храниться конфиденциальная информация. В число таких действий обязательно должно входить требование по извещению пользователями сотрудников Департамента по безопасности и информационным технологиям. Все случаи утери мобильных устройств должны быть обработаны в соответствии с требованиями внутренних нормативных документов, а результаты (включая уведомления от пользователей об утере) – документированы в установленной форме. Cтр. 12 из 32 6.2.3.4. Должны применяться дополнительные меры и средства защиты для мобильных устройств, не соответствующих требованиям настоящего Стандарта и иных документов Компании в области ИБ. Недопустимо применение мобильных устройств, не соответствующих корпоративным требованиям по ИБ, для доступа к ресурсам корпоративной сети. 6.2.3.5. Должна быть установлена ответственность пользователей за физическую безопасность мобильного устройства, это требование должно быть доведено до пользователей. 6.2.3.6. Рекомендуется применять антивирусное программное обеспечение на мобильных устройствах. В случае принятия решения об использовании таких средств защиты, рекомендуется установить соответствующие требования внутренними нормативными документами Компании. 6.2.3.7. Рекомендуется применять на мобильных устройствах локальные средства межсетевого экранирования и предотвращения вторжений. В случае принятия решения об использовании таких средств защиты, рекомендуется установить соответствующие требования внутренними нормативными документами Компании. 6.2.3.8. Рекомендуется осуществлять шифрование конфиденциальной информации, хранящейся на мобильных устройствах. Рекомендуется регламентировать требования к шифрованию конфиденциальной информации на мобильных устройствах и к соответствующим средствам шифрования во внутренних нормативных документах Компании. 6.2.4 О БЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ НА СТАДИЯХ ЖИЗНЕННОГО ЦИКЛА ИНФОРМАЦИОННЫХ СИСТЕМ Рассматриваются следующие стадии жизненного цикла информационных систем: • Стадия разработки (проектирования) и модернизации. • Стадия эксплуатации. • Стадия вывода из эксплуатации. Стадия разработки (проектирования) и модернизации: 6.2.4.1. Должно осуществляться формирование требований по ИБ к внедряемым, разрабатываемым или дорабатываемым системам. При этом требования и новый функционал должны быть согласованы с Управлением защиты информации. Результаты согласования должны быть зафиксированы документально. 6.2.4.2. Должны разрабатываться методики тестирования и проведения приемочных испытаний в каждом случае внедрения новых информационных систем, сервисов, инфраструктурных решений или доработки уже существующих. Эти методики должны включать в себя проверку выполнения ранее сформированных требований по ИБ. Приемочные испытания должны проводиться в соответствии с вышеуказанными методиками, а результаты приемочных испытаний должны быть документированы. 6.2.4.3. Должен быть назначен сотрудник, ответственный за выполнение процедуры внесения изменений в информационные системы, сервисы, настройки сетевых устройств и средств защиты информации. 6.2.4.4. Должен быть установлен перечень лиц, ответственных за согласование изменений, вносимых в информационные системы, сервисы, настройки сетевых устройств и средств защиты информации. 6.2.4.5. Должен быть реализован механизм обратимости вносимых изменений, т.е. должен существовать способ (резервная система, обратная последовательность операций, архив исходного кода системы и т.п.), позволяющий в случае необходимости вернуть изменяемый ресурс в исходное состояние. 6.2.4.6. Рекомендуется не использовать при разработке и тестировании информационных систем реальных данных продуктивных систем, содержащих конфиденциальную информацию. Рекомендуется при разработке и тестировании использовать специально подготовленные тестовые данные. Соответствующие требования, в случае их принятия, должны быть установлены внутренними нормативными документами Компании. Cтр. 13 из 32 Стадия эксплуатации: 6.2.4.7. Должна быть реализована сегментация локальной сети Компании, как минимум в отдельные сегменты сети должны быть выделены среды разработки и тестирования. Должна осуществляться фильтрация входящего и исходящего траффика по отношению к сегментам разработки и тестирования. 6.2.4.8. Должно осуществляться внесение изменений на основании соответствующих заявок, согласованных с владельцами информационных активов, на которые могут оказать влияние планируемые к внесению изменения. Заявка на внесение изменений должна включать в себя, как минимум: • Ожидаемое воздействие изменений на информационные ресурсы Компании. • Описание необходимых системных, программных и человеческих ресурсов. • Определение времени и (или) условий проведения изменений. • Порядок действий при внесении изменений и ожидаемый результат. • Порядок контроля результатов внесения изменений. • Процедуры возврата к первоначальному состоянию системы. • Критерии принятия решения об успешном завершении процесса изменения. Аварийные (экстренные) изменения могут быть внесены без предварительного согласования на основании решения сотрудника, ответственного за выполнение процедуры внесения изменений. 6.2.4.9. Должно проводиться тестирование работоспособности информационных систем и сервисов после внесения аварийных (экстренных) изменений, в соответствии с установленными требованиями по управлению изменениями. 6.2.4.10. Должно осуществляться внесение плановых изменений исключительно после успешного завершения тестирования, если необходимость такого тестирования установлена, в соответствии с установленной процедурой управления изменениями. Результаты тестирования должны документироваться. 6.2.4.11. Должно проводиться тестирование работоспособности информационных систем и сервисов после внесения плановых изменений, не требующих предварительного тестирования. Такое тестирование проводится в соответствии с установленной процедурой управления изменениями. Результаты тестирования должны документироваться. 6.2.4.12. Рекомендуется осуществлять внесение плановых изменений на основании заранее разработанных и утвержденных планов, включающих в себя планы отката изменений. При принятии этого требования рекомендуется документировать его во внутренних нормативных документах. 6.2.4.13. Рекомендуется для всех ресурсов корпоративной сети на основании критичности обрабатываемых информационных активов и предоставляемых ими сервисов, а также с точки зрения экономической целесообразности, принять и документировать решение об очередности внесения и тестирования плановых изменений: • Тестирование до внесения изменений (рекомендуется для большинства информационных систем). • Тестирование после внесения изменений (допустимо для сетевого оборудования). 6.2.4.14. Рекомендуется документировать результаты внесения изменений. В случае принятия решения о документировании результатов изменений, рекомендуется регламентировать это требование во внутренних нормативных документах. 6.2.4.15. Рекомендуется перед внесением аварийных (экстренных) изменений сформировать планы откатов изменений. В случае принятия решения о формировании таких планов рекомендуется регламентировать это требование во внутренних нормативных документах. Стадия вывода из эксплуатации: 6.2.4.16. Должно осуществляться ограничение доступа пользователей к информационным системам, переводимым в архивный режим. При этом, при наличии производственной необходимости, Cтр. 14 из 32 пользователям может быть предоставлен доступ на чтение на основании соответствующих заявок. Перевод систем в архивный режим должен фиксировать документально актами. 6.2.4.17. Должно осуществляться уничтожение данных, содержащихся на электронных носителях (в том числе носителей резервных копий), выводимых из эксплуатации. Такое уничтожение должно проводиться с использованием методов гарантированного уничтожения. 6.2.4.18. Внутренними нормативными документами должны быть установлены требования к уничтожению бумажных носителей конфиденциальной информации. В соответствии с этими требованиями должна быть реализована процедура уничтожения бумажных носителей конфиденциальной информации надежным способом (например: в шредере, путем сжигания или при помощи специализированной компании). Такое уничтожение должно проводиться в присутствии ответственных сотрудников Компании 6.2.5 О БЕСПЕЧЕНИЕ АНТИВИРУСНОЙ ЗАЩИТЫ 6.2.5.1. Должно применяться антивирусное программное обеспечение на всех технических средствах и для всех операционных систем Компании. 6.2.5.2. Должна применяться эшелонированная антивирусная защита, предусматривающая использование средств антивирусной защиты различных производителей, в том числе на следующих компонентах корпоративной сети: • Пользовательском оборудовании, включая на рабочие станции. • Серверном оборудовании, включая серверы электронной почты. • Технических средствах межсетевого экранирования. 6.2.5.3. Антивирусные средства должны обладать способностью защиты от всех известных видов вредоносного программного обеспечения. Средства антивирусной защиты должны позволять осуществлять обнаружение и нейтрализацию вредоносного ПО, содержащегося: • На жестких дисках, съемных носителях информации и в оперативной памяти. • В архивах и в упакованных объектах. • В веб-траффике. • В входящих и исходящих сообщениях электронной почты. 6.2.5.4. Антивирусное ПО должно обладать функционалом защиты от вирусов в режиме реального времени. 6.2.5.5. Должно осуществляться обновление антивирусного ПО в соответствии с заданной в Компании периодичностью, но не реже одного раза в 3 часа. 6.2.5.6. Должно выполняться антивирусное сканирование: • Периодическое сканирование жёстких дисков и оперативной памяти с частотой, как минимум, один раз в неделю. • При подключении съемных носителей информации. 6.2.5.7. Должны регистрироваться следующие события антивирусного ПО: • Обнаружение вредоносного ПО и действий по результатам такого обнаружения. • Изменение настроек антивирусного ПО. • Обновление антивирусного ПО и вирусных сигнатур. 6.2.5.8. Должен осуществляться периодический мониторинг событий, зарегистрированных антивирусным ПО. 6.2.5.9. Рекомендуется проводить внеочередное антивирусное сканирование после внесения изменений в программную среду серверов и рабочих станций. В случае, если будет принято решение о проведении такого сканирования, соответствующее требование должно быть установлено во внутренних нормативных документах. 6.2.6 Б ЕЗОПАСНОСТЬ СЕТИ И СЕТЕВОГО ДОСТУПА 6.2.6.1. Должна поддерживаться в актуальном состоянии схема сети, для этого: Cтр. 15 из 32 • Должен проводиться регулярный пересмотр схемы сети с целью поддержания ее актуальности. • В схему сети должны своевременно вноситься обновления в случае любых значимых изменений в сетевой инфраструктуре. 6.2.6.2. Должны быть отражены (как минимум) на схеме сети: • Все сегменты корпоративной сети Компании. • Все сетевое оборудование 3-го уровня модели OSI. • Все подключения к внешним сетям. 6.2.6.3. Должна быть реализована сегментация корпоративной сети. Сеть должна быть сегментирована в соответствии со следующими требованиями: • Выделить в отдельный сегмент сети демилитаризованную зону (DMZ), и расположить в этом сегменте все сервисы, доступные из внешних сетей. • Сетевые сегменты, содержащие серверы продуктивных систем, должны быть отделены от прочих сегментов ЛВС, в том числе от сегментов которые содержат рабочие станции пользователей. • Беспроводные сети должны быть выделены в отдельные сегменты сети. 6.2.6.4. Должен быть запрещен прямой трафик из внешних сетей во внутренние сегменты корпоративной сети, за исключением сегмента DMZ. 6.2.6.5. Должна осуществляться фильтрация трафика в соответствии с требованиями внутренних нормативных документов: • Между внешними сетями и DMZ. • Между внутренними сегментами сети, отделенными друг от друга (в число таких сегментов входят: DMZ, серверные сегменты, сегменты пользователей, беспроводные сети). 6.2.6.6. Должны вестись реестры правил межсетевого экранирования, позволяющие осуществлять контроль правил межсетевого экранирования. Для ведения таких реестров могут использоваться специализированные автоматизированные средства. Реестры правил межсетевого экранирования должны включать в себя, как минимум все действующие правила фильтрации ЛВС. 6.2.6.7. Должен осуществляться периодический пересмотр реестра правил межсетевого экранирования для оценки актуальности правил межсетевого экранирования, а также для оценки связанных с ними рисков. Периодичность пересмотра должна быть не реже одного раза в год. 6.2.6.8. Должен быть составлен перечень разрешенных к использованию сетевых протоколов. В случае использования небезопасных протоколов (протоколов, не передающих аутентификационную информацию в зашифрованном виде), должны быть определены соответствующие защитные меры. 6.2.6.9. Должны использоваться только разрешенные к использованию протоколы, которые документированы в перечне, разработанном в соответствии с требованием предыдущего пункта. 6.2.6.10. Должен контролироваться обмен данными с внешними сетями при помощи систем обнаружения/предотвращения вторжений. Системы обнаружения/предотвращения вторжений должны контролировать весь трафик, поступающий из внешних сетей. 6.2.6.11. Должно осуществляться обновление баз данных систем обнаружения/предотвращения вторжений в соответствии с требованиями внутренних нормативных документов. Обновление сигнатур систем обнаружения/предотвращения вторжений должно осуществляться не реже одного раза в день. 6.2.6.12. Рекомендуется в реестрах правил межсетевого экранирования указывать: • Назначение каждого правила межсетевого экранирования. • Инициатора создания правила. 6.2.7 Р ЕГИСТРАЦИЯ И МОНИТОРИНГ СОБЫТИЙ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 6.2.7.1. Должны быть определены информационные системы и сервисы, для обеспечения безопасности и доступности которых необходимо осуществлять регулярный мониторинг событий ИБ, регистрируемых на системных компонентах, которые входят в состав этих систем и сервисов. В число Cтр. 16 из 32 таких системных компонентов могут входить: ОС, СУБД и ППО информационных систем, а также СЗИ и сетевое оборудование. 6.2.7.2. Должен осуществляться мониторинг событий ИБ, зарегистрированных на всех системных компонентах критичных информационных систем и сервисов, а также на всех средствах защиты информации и сетевом оборудовании, в соответствии с требованиями, установленными в Компании. 6.2.7.3. Должна быть настроена регистрация событий ИБ на всех системных компонентах информационных систем, на всех средствах защиты информации и сетевом оборудовании. В число таких событий должны входить, как минимум, следующие: • Использование механизмов идентификации и аутентификации. • Неуспешные попытки логического доступа. • Любые действия пользователя ИС с персональными данным (согласно пп.8 п.2 ст.19 №152-ФЗ). • Блокировка учетной записи в результате превышения лимита неверных попыток входа. • Любые действия, совершенные с использованием административных полномочий. • Создание/удаление учетных записей. • Создание/удаление групп пользователей/ролей доступа. • Изменения настроек синхронизации системного времени. • Запуск и остановка сервисов. • Доступ к журналам событий ИБ. • Срабатывание сигнатур системы обнаружения вторжений. • Обнаружение вредоносного ПО. 6.2.7.4. Для каждого события ИБ должна регистрироваться, как минимум, следующая информация: • Название/идентификатор системного компонента, на котором зарегистрировано событие. • Идентификатор пользователя. • Тип события. • Дата и время. • Успешным или неуспешным было событие. • Источник события (например, ip адрес клиента, название рабочей станции и т.п.). • Идентификатор объекта, на который повлияло событие. 6.2.7.5. Должно осуществляться хранение журналов аудита событий ИБ не менее 12 месяцев, в соответствии с установленными требованиями Компании. 6.2.7.6. Должен быть ограничен доступ к журналам аудита событий ИБ и предоставлен только тем работникам, которым он необходим для осуществления должностных обязанностей. 6.2.7.7. Должно быть синхронизировано с единым источником точного времени системное время всех информационных систем. 6.2.7.8. Должен быть реализован автоматизированный мониторинг событий ИБ при помощи специализированной системы управления событиями ИБ. При помощи системы управления событиями ИБ должно осуществляться уведомление работников Компании, ответственных за ИТ и ИБ, обо всех критичных событиях ИБ. 6.2.7.9. Должен быть определен перечень системных компонентов, подключаемых к системе управления событиями ИБ для централизованного автоматизированного мониторинга. Как минимум в число таких системных компонентов должны войти: • Сетевое оборудование (межсетевые экраны и системы обнаружения вторжений, VPN-шлюзы и т.д.). • Средства защиты информации. • ОС, СУБД и ППО критичных для бизнес-процессов Компании информационных систем. 6.2.7.10. Рекомендуется осуществлять мониторинг событий ИБ в режиме 24х7. В случае принятия такого решения, следует зафиксировать режим мониторинга событий ИБ во внутренних нормативных документах Компании. |