четверг, 7 марта 2019 г.

КИИ. ОКВЭД vs 187-ФЗ


Все ещё одним из наиболее часто задаваемых вопросов про КИИ является: попадаем ли мы в сферы 187-ФЗ?  Например, если мы школа или учреждение соц. защиты.

Чтобы ответить на этот вопрос в первую очередь рекомендуется посмотреть на коды ОКВЭД вашей организации и сравнить с кодами ОКВЭД в которые попадают сферы и отрасли из 187-ФЗ. Если по каким -то причинам вам это было сложно сделать, то специально в честь наступающего праздника я сделал это за Вас. Пользуйтесь:   



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

пятница, 1 марта 2019 г.

ИБ. Памятка для пользователей систем банк-клиент и ДБО

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

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

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

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

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

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

понедельник, 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, запрещающие эксплуатацию всех ранее созданных ГИС, если в них не выполнены требования о защите информации, в том числе если:
·         МУ и ТЗ на ГИС не согласованы с регуляторами
·         не учитываются угрозы из БДУ ФСТЭК
·         используются не аттестованные ЦОД
·         мониторинг ИБ без новой лицензии
·         отсутствует действующий аттестат на ГИС   и т.п.