понедельник, 18 февраля 2019 г.

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


13 февраля 2019 г.  постановлением правительства РФ № 146 утверждены “Правила организации и осуществления государственного контроля и надзора за обработкой персональных данных”.

Сравниваем с действующим административным регламентом функции по осуществлению государственного контроля (надзора) за соблюдением обработки персональных данных требованиям законодательства Российской Федерации в области персональных данных от 14.11.2011 № 312

Основные изменения:
·         Явно исключили контроль за выполнением организационных и технических мер по обеспечению безопасности ПДн
·         Соответственно убрали возможность Роскомнадзора привлекать к государственному контролю внешних экспертов (по обеспечению безопасности)
·         Обычная периодичность проведения плановых проверок осталась такой же – не чаще чем раз в 3 года. Но добавили 4 исключения, когда периодичность проведения плановых проверок может составлять 2 года: оператор ГИС, специальные категории ПДн и биометрия, трансграничная передача, поручение на обработку от иностранных лиц и компаний.
·         Новые основания для проведения внеплановых проверок:
o   обращения граждан при условии предоставления подтверждающих материалов
o   если в результате контролю без взаимодействия с оператором выявлены нарушения
·         Кроме планового и внепланового контроля определены ещё 2 типа мероприятия по контролю:
o   контроль без взаимодействия с оператором
o   профилактика нарушений
·         Протоколы об административном нарушении можно составлять в том числе по результатам “контроля без взаимодействия с оператором”
·         На предоставление документов в рамках документарной проверки дается теперь не 10, а всего 5 рабочих дней; на предоставление пояснений всего 3 дня. При несоблюдении сроков, документарная проверка переходит в выездную проверку.
·         Теперь можно понять, как будут развиваться события в случае, если оператор не собирается устранять нарушения или полностью бездействует:
o   Проводится удаленный контроль без участия оператора
o   Выдается предписание устранить нарушение в 10 дневной срок и сообщить в РКН (+ протокол по КОАП 13.11)
o   Назначается внеплановая выездная проверка
o   В случае бездействия оператора = воспрепятствование проведению проверки - привлекаются правоохранительные органы (+ протокол по КОАП 19.4.1)
o   Предписание устранить нарушение в срок установленный Роскомнадзором (+ протокол по КОАП 19.5)
o   Предписание о приостановлении деятельности по обработке ПДн
o   Меры предусмотренные 152-ФЗ по прекращению обработки ПДн с нарушениями (внесение в Реестр нарушителей + блокирование доступа к сайту)



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


понедельник, 11 февраля 2019 г.

ИБ. Лучшие практики мер безопасности из Германии


7 февраля Ассоциация ИТ-безопасности Германии TeleTrusT подготовила и при поддержке ENISA перевела на английский язык руководство “Современный уровень” (State of the art) технических и организационных мер для немецкого закона IT Security Act и европейского GDPR.

В упомянутых НПА неоднократно говорится, что при выборе мер защиты необходимо принимать во внимание современный уровень техники (State of the art), наряду с затратами на меры защиты, объемом и целями обработки данных, вероятностью риска и степенью возможного вреда. Ранее нигде не было определено что такое современный уровень техники (State of the art) в ИТ безопасности и ассоциация TeleTrusT решила это исправить.

Была выбрана методология, по которой все меры защиты разделялись на 3 уровня:
·         existing scientific knowledge and research (ESKaR) – научные знания и исследования
·         state of the art (STOA) – современный уровень техники
·         generally accepted rules of technology (GART) – общепринятые правила техники “несовременные”

Рабочая группа “State of the art” подготовила опросник, по которому каждая мера оценивалась по степени признания и степени проверки на практике. Они многократно повторили цикл оценки, в том числе с привлечением внешних экспертов и получили следующий перечень современных мер.

Технические меры:
·         Безопасность серверов (Server hardening)
·         Оценка надежности паролей (Password strength assessment)
·         Обеспечение применения надежных паролей (Enforcing strong passwords)
·         Многофакторная аутентификация (Multi-factor authentication)
·         Криптографические процедуры (Cryptographic procedures)
·         Шифрование диска (Disk encryption)
·         Шифрование файлов и папок (Encryption of files and folders)
·         Шифрование электронной почты (E-mail encryption)
·         Инфраструктура PKI для безопасности коммуникаций (Securing electronic data communication with PKI)
·         Шифрование каналов связи на 3 уровне - VPN (Use of VPNs (layer 3))
·         Шифрование на 2 уровне (Layer 2 encryption)
·         Безопасность облачного обмена файлами (Cloud-based data exchange)
·         Безопасность данных, хранимых в облаке (Data storage in the cloud)
·         Безопасное использование мобильных сервисов (Use of mobile voice and data services)
·         Безопасность сервисов мгновенного обмена сообщениями (Communication through instant messenger)
·         Управление мобильными устройствами (Mobile Device Management)
·         Безопасность активного сетевого оборудования (Router security)
·         Обнаружение вторжений (Network monitoring using Intrusion Detection System)
·         Web фильтрация (Web traffic protection)
·         Безопасность web приложений (Web application protection)
·         Безопасный удаленный доступ (Remote network access/ remote maintenance)

Организационные меры:
·         Процессы ИБ
o   Назначение ответственности за ИБ (Security organisation)
o   Управление требованиями ИБ (Requirements management)
o   Управление перечнем ИС (Management of scope of application)
o   Управление политиками ИБ (Management of information security guidelines)
o   Управление рисками ИБ (Risk management)
o   Управоление применимостью требований (Management of statement of applicability)
o   Управление ресурсами ИБ (Resource management)
o   Управление знаниями ИБ (Knowledge and competency management)
o   Управление документацией и коммуникациями (Documentation and communication management)
o   Управление ИТ сервисами (IT service management)
§  Управление активами (Asset Management)
§  Повышение осведомленности (Training and awareness)
§  Эксплуатация (Operation)
§  Управление инцидентами (Incident Management)
§  Управление неприрывностью (Continuity Management)
§  Приобретение (Procurement)
§  Разработка и внедрение (Software development and IT projects)
o   Анализ эффективности (Performance monitoring management)
§  Технические аудиты (Technical system audits)
§  Аудиты соответствия, сертификации (Internal and external audits, ISMS certification)
o   Управление улучшениями (Improvement management)
·         Безопасная разработка ПО
·         Аудиты и сертификация

По каждой технической мере указывается какие угрозы она нейтрализует и даются краткие ре рекомендации по её выполнению. Например, в криптографии: “TLS25, 26: TLS 1.3 combined with forward secrecy using secure algorithms as per BSI TR-02102-2, table 127. The use of tools such as: https://www.owasp.org/index.php/O-Saft and https://www.ssllabs.com/ssltest/ helps inspect TLS configuration.”

По организационным мерам – похуже. Для их оценки проводился не опрос специалистов, а анализ стандартов ISO, BSI, Cobit. Сами орг. меры описаны кратко – придется лезть в упомянутые стандарты за деталями.
Данный перечень рекомендуется как первый шаг при определении достаточных мер защиты и не заменяет консультации и индивидуальную оценку с учетом особенностей конкретной организации. 
В целом документ сравним с top20 мер защиты от SANS, только меры частично другие. Если кому-то будет интересно, в других статьях могу рассмотреть подробно отдельные меры.


четверг, 24 января 2019 г.

ИБ. Экономика и лучшие практики раскрытия уязвимостей


А помните в прошлом году один человек нашел баг в ГИС Минобра, выкачала базу дипломов, не смог связаться с администратором и опубликовал статью с примерами эксплуатации на Хабр?

Под новый год ENISA (регулятор по ИБ евросоюза) опубликовал интересный документ по анализу и экономике процессов раскрытия уязвимостей - Economicsof Vulnerability Disclosure. В своем исследовании они опирались также на другой свежий документ - Software Vulnerability Disclosure in Europe от CEPS.

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



Рассматриваются текущие практики раскрытия и нераскрытия уязвимостей:


В документе отмечается что развитие платформ bug bounty положительно повлияло на развитие процессов сообщения об уязвимостях, на привлечение внимания к теме уязвимостей. Средние стоимости вознаграждений. Но bug bounty платформ также есть свои ограничения и недостатки: в том числе что закрытые приложения и критические объекты не могут участвовать в публичных программах поиска уязвимостей, а также то что все bug bounty платформы расположены в США.  

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

Во втором документе по результатам анализа даются конкретные рекомендации, которые необходимо принять в евросоюзе. Если переложить их на РФ, то они звучали бы примерно так:
·         Утвердить политику раскрытия уязвимостей (Coordinated Vulnerability Disclosure Policy) на национальном уровне.   Что-то подобное уже есть на сайте БДУ ФСТЭК, но освещает далеко не все вопросы и мало кто о ней знает.
·         Разработать рекомендации по политике раскрытия уязвимостей для производителей.
·         Разработать рекомендации по принятию решения в рамках раскрытия уязвимостей (government disclosure decisions processes - GDDP): в зависимости от масштаба уязвимости, сложности устранения – можно ли раскрывать, в каком объеме, кому, в какие сроки.
·         Внести изменение в законодательство РФ, в котором должно быть определено:
o   Разрешено ли искать уязвимости? (сейчас фактически это вне закона)
o   Границы и правила, которые необходимо соблюдать
o   Имеются ли ограничения на публикацию
o   Разрешено ли торговать информацией об уязвимостях
o   Имеются ли какие-то ограничение на продажу информации об уязвимостях
·         В базовый набор мер защиты по ПДн, ГИС и КИИ добавить необходимость разработки и публикации CVP политики. Производителей из реестра российского ПО обязать указывать контакт для взаимодействия по вопросам уязвимостей.
·         Развивать национальный CERT портал, на котором можно публиковать информацию об уязвимостях и найти контакт вендора для взаимодействия по вопросам уязвимостей – частично решает БДУ ФСТЭК.
·         Создать российскую платформу для bugbounty для возможности запуска программ по поиску уязвимостей в ГИС и КИИ РФ
·         Выделить бюджет на поиск уязвимостей и bugbounty в ключевых гос. активах  


PS: Ссылки на другие полезные документы:




четверг, 17 января 2019 г.

ИБ. Госуслуги остались без защиты?


Пару дней назад обновился реестрсертифицированных СЗИ в системе ФСТЭК России. Там появились свеже сертифицированные серийные СЗИ. Но мне было интересно посмотреть на некоторые штучные.

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


И в этом ключе довольно странно выглядит не продление сертификатов ФСТЭК на ПО портала Госуслуги и СМЭВ, и удаление ФСТЭКом этих сертификатов из перечня (а ведь в соответствии с новым положением о сертификации допускается эксплуатация СЗИ даже с истекшим сроком, только если ФСТЭК не отзовет его и удалит из перечня).   


Если посмотреть на планы модернизации СМЭВ – там есть переделка подсистемы безопасности, но это в срок до 2020 года. А что с защитой СМЭВ и Госуслуг сейчас? Надеюсь на замену сертифицированному ПО Госуслуги и СМЭВ, владельцем (Минкомсвязи) и оператором (Ростелеком) приняты иные меры защиты с применением накладных СЗИ (а также проведена аттестация в связи с заменой СЗИ) …   


PS: также хочу напомнить коллегам, отвечающим за ГИС, что с 01 января 2019 вступилив силу изменения в Постановление правительства №678, запрещающие эксплуатацию всех ранее созданных ГИС, если в них не выполнены требования о защите информации, в том числе если:
·         МУ и ТЗ на ГИС не согласованы с регуляторами
·         не учитываются угрозы из БДУ ФСТЭК
·         используются не аттестованные ЦОД
·         мониторинг ИБ без новой лицензии
·         отсутствует действующий аттестат на ГИС   и т.п.

  

среда, 26 декабря 2018 г.

КИИ. Категорирование объектов, часть 4. Высокоуровневая оценка ущерба КИИ


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

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

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

Требования, как необходимо проводить анализ угроз в рамках категорирования объектов КИИ – отсутствуют. Есть только требования к сведениям, которые необходимо предоставить в результате анализа.  А значит мы можем выбрать свою произвольную методику, которая будет давать нам подходящий результат. Ниже представляю самый простой вариант высокоуровневой оценки ущерба КИИ. Простые методики могут быть грубоваты для крупных и сложны систем, но для типовых систем небольших организаций они отлично заходят – вот пример c ENISA для SMB. При высокоуровневой оценке никакие контрмеры не учитываются (такое указание ФСТЭК).

1)      Рассмотреть возможности нарушителей, определить их категории и краткую характеристику …
Перечень возможных нарушителей, их мотивацию и возможности берем из проекта методического документа “Методика определения угроз безопасности информации в ИС” от 2015 г. Там они отлично описаны.

Если вам лень выписывать самим, то на картинке ниже, я сделал подборку по мотивации и возможностям

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

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

3)      Определяем основные угрозы
·         Берем список (из того же проекта методики):
o   несанкционированного доступа и (или) воздействия на объекты на аппаратном уровне (программы (микропрограммы), «прошитые» в аппаратных компонентах (чипсетах))
o   несанкционированного доступа и (или) воздействия на объекты на общесистемном уровне (базовые системы ввода-вывода, гипервизоры, операционные системы)
o   несанкционированного доступа и (или) воздействия на объекты на прикладном уровне (системы управления базами данных, браузеры, web приложения, иные прикладные программы общего и специального назначения)
o   несанкционированного доступа и (или) воздействия на объекты на сетевом уровне (сетевое оборудование, сетевые приложения, сервисы)
o   несанкционированного физического доступа и (или) воздействия на линии, (каналы) связи, технические средства, машинные носители информации
o   воздействия на пользователей, администраторов безопасности, администраторов информационной системы или обслуживающий персонал (социальная инженерия)
·         Убираем угрозы, связанные с компонентами, которых нет в составе вашего объекта КИИ (разве что, сетевое оборудование, остальное исключить не можем)

4)      Определяем типы инцидентов
·         Берем список (из п. 7.1 приказа ФСТЭК №236)
o   отказ в обслуживании
o   несанкционированный доступ
o   утечка данных (нарушение конфиденциальности)
o   модификация (подмена) данных
o   нарушение функционирования технических средств
o   несанкционированное использование вычислительных ресурсов объекта
·         Исключаем типы инцидентов, которых не может быть с вашим объектом. Но если честно, то я не вижу возможности исключит хоть какие-то. Разве что у вас вся информация общедоступная и нарушение конфиденциальности невозможно.
·         Если бы мы могли гибко выбирать нарушителей, то могли бы сказать, что наши нарушители с низким потенциалом смогут провести только простые атаки – например на отказ в обслуживании. А более сложные атаки, связанные с подменой данных требуют уже изучения технологических процессов и соответственно доступны только нарушителю со средним потенциалом. Но нарушителей исключать мы фактически не можем и у нас там есть со средним потенциалом.  

5)      Оцениваем степень ущерба или степень автоматизации процесса (промежуточный коэфициент)
·         Теперь самый ответственный момент категорирования. Все вычисления, проведенные на этапе 1-4 носят исключительно справочный характер (зачем то их прописали в ПП 127)
·         Нам необходимо оценить насколько Критический процесс зависит от объекта КИИ:
o   высокая, если в результате инцидентов, возможно полное нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ
o   средняя, если в результате инцидентов, возможно частичное нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ
o   низкая, если в результате инцидентов, не происходит нарушение или прекращение процессов, обеспечиваемых данным объектом КИИ
·         При оценке нельзя учитываться дублирующие компоненты и системы. Нельзя принимать в расчет резервное копирование, восстановление и другие контрмеры.
·         Пример 1: все оказанные мед. услуги, полученные диагнозы, назначенные лечения, фиксируются в электронном виде. При оказании услуг врач в первую очередь смотрит данные в системе, и только если они отсутствуют, тогда только начинают запрашивать бумажные карточки, предыдущие справки и диагнозы на бумажных носителях. В таком случае степень ущерба ставим высокую.   
·         Пример 2: вся текущая работа с клиентом идет без использования системы и только в конце, когда услуги уже указаны для отчетности вышестоящей Организации информация заносится в систему. Наша организация данные из системы никак не использует. Ставим степень ущерба низкую.

6)      Оцениваем ущерб (возможные последствия)
·         Наконец оцениваем ущерб от компьютерных инцидентов, по показателям значимости из ПП 127.
·         Для этого берем оценку возможного ущерба от нарушения Критического процесса и применяем к нему коэфициент Степень автоматизации  
o   Если степень автоматизации высокая, то ущерб от компьютерного инцидента на объекте КИИ аналогичен ущербу от нарушения Критического процесса, который обеспечивает данный объект КИИ  
o   Если средняя, то ущерб от компьютерного инцидента на одну категорию ниже негативных последствий, которые могут произойти при нарушении и (или) прекращении процессов
o   Если низкая, то ущерб от компьютерного инцидента соответствует негативным последствиям, не попадающим в категорию значимости










7)      Определяем категорию объекта КИИ как максимум из категорий по отдельным показателям ущерба
Собственно, на этом все – записываем результаты и отправляем уведомление во ФСТЭК.

Наверное, статья была бы не полной без примеров. Вот несколько для здравоохранения.


Если у вас ещё остаются вопросы по категорированию, обращайтесь – вместе решим.

PS: Возможность категорирования объектов КИИ мы добавили в последнем обновлении системы DocShell, в месте с другими возможностями автоматизации задач в сфере безопасности КИИ.

PPS: На всякий случай напомню общий порядок категорирования объектов КИИ (он немного менялся по результатам общения с регуляторами):
·         Определяем, что Организация действует в сфере КИИ (187-ФЗ) и хотя бы одна любая система = у нас есть процессы в сферах КИИ + любая система = мы Субъект КИИ
·         Из процессов Организации в сферах КИИ определяем Критические процессы
·         Только для Критических процессов определяем системы, которые их обеспечивают и только они попадают в Перечень объектов КИИ
·         Определяем категории только для объектов КИИ из Перечня  
При этом, пожалуй, самым трудоемким является оценка Критичности процесса – по сути именно там мы определяем, какой возможен максимальный ущерб. А остальной анализ – это сколько из этого максимума оставить.