вторник, 16 апреля 2019 г.

КИИ. Планирующиеся штрафы за нарушение требований в области КИИ


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

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

В пояснительной записке указывается что авторы считают, что имеющаяся статья 274.1 УК РФ слишком суровая для обычного нарушения требований, поэтому предлагают дифференцированный подход: часть новых пунктов распространяется на всех субъектов КИИ, а другая – только на владельцев значимых объектов КИИ.
Ниже все штрафы на одной картинке

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

PS: Законопроект выглядит логичным. Из личного общения с субъектами КИИ могу сделать вывод что наличие таких статей может существенно ускорить (с бесконечности до каких-то 3 лет) работы по ОБ КИИ.  

Пункты нарушений привязаны к конкретным НПА – ты отлично понимаешь, что за невыполнение данного конкретного документа будет именно такой-то пункт КОАП РФ.  В отличие от этого, по ПДн пункты нарушений какие-то выборочные – можно нарушить 90% требований, но под это не будет подходящей статьи и тебя просто не смогут наказать – только пожурить.

PPS: Диапазон сумм штрафов могли бы сделать и побольше, так как некоторые субъекты КИИ – это крупные корпорации и для них такие суммы всё ещё копеечные. На этом фоне более серьезными выглядят штрафы для должностных лиц – заплатить такие из собственного кармана уже не хотелось бы (340 тыс. руб. если нарушил всё что можно).

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

ИБ. Лучшие практики CIS. 20 ключевых мер защиты




Недавно международное ИТ сообщество CIS (Center for Internet Security) обновили свой документ с лучшими практиками (20 CIS Controls) мер защиты от актуальных угроз ИБ.  В обновлении немного поменялись формулировки мер защиты, угроз которым они противостоят, а также добавлен новый подход к приоритизации мер, под названием – группы реализации Implementation Group, о которых надо рассказать подробнее:

Изначально TOP 20 CIS Critical control – это был набор групп мер приоритезированных по критичности и рекомендованному порядку их применения. Причем первые Basic меры считались основами кибер гигиены, которые должны внедрить все компании (подробнее в моих предыдущих заметках)

Но оказалось, что для некоторых малых и ограниченных в ресурсах компаний не по силам даже Basic группы меры. К тому же раньше не учитывалась разная степень риска в разных организациях.  Поэтому решено было разделить меры на группы реализации IG1, IG2, IG3
         Implementation group 1 - IG1
Организация применяющие IG1 – в основном малый (иногда средний бизнес), с ограниченным опытом в ИТ и кибербезопасности. Основная задача этих организаций - сохранить бизнес в рабочем состоянии, а основной ущерб - от простоя.  Как правило обрабатывают не критичные данные своих сотрудников и финансовую информацию. Если же организации малого бизнеса обрабатывают критичные данные, то должны выполнять меры следующих групп.
Меры защиты, реализуемые в рамках группы IG1, должны осуществляться в варианте требующем минимум компетенций в области ИБ и рассчитаны на коробочные решения оборудования и ПО для малого бизнеса.

         Implementation group 2 – IG2
В организациях, применяющих IG2 как правило есть выделенные работники отвечающие за управление ИБ и защиты ИТ инфраструктуры. В таких организациях есть процессы и подразделения разной степени критичности. Некоторые подразделения могут быть нацелены в первую очередь на выполнение требований законодательства (compliance).  
Организации группы IG2 как правило обрабатывают важную информацию своих клиентов и контрагентов и устойчивы к коротким перерывам в обслуживании. Основное беспокойство вызывает потеря репутации в случае инцидентов.
Частные меры группы IG2, помогают ответственным за безопасность лицам, справляться с возрастающей сложностью процессов и операций. Установки и настройки некоторых меры будут зависеть от имеющегося в компании уровня технологий и экспертизы.

         Implementation group 3 – IG3
В организациях группы IG3 тысячи работников, в том числе имеются эксперты по безопасности, которые специализируются на различных аспектах кибербезопасность (например, управление рисками, тестирование на проникновение, безопасность приложений). Системы и данные организаций группы IG3 содержат конфиденциальную информацию или функции, которые строго регулируются или должны соответствовать требованиям.

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

Пример, таблицы соответствия мер “Инвентаризация и контроль ПО” и групп применения. 



Не правда ли, похоже на уже привычные по документам ФТСЭК / NIST базовые наборы мер в зависимости от класса систем.  Кстати, у CIS уже есть таблицы соответствия CIS Controls NIST CSF, а значит легко можно сделать аналогичную таблицу соответствия мерам из приказов ФСТЭК.

Далее можно использовать лучшее что есть в CIS Controls – порядок реализации мер начиная с наиболее важных, рекомендации по реализации процедур и использованию решений по автоматизации мер, метрики для контроля эффективности мер.  При этом всё это в общем то не будет противоречить российскому законодательству по ИБ.


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

ИБ. Единое встроенное СЗИ


Сегодня Ассоциация российских разработчиков единого встроенного СЗИ, включающая Россети, Газпром, Лукойл, Сбербанк, опубликовала пресс релиз о выпуске Единого встроенного средства защиты информации (далее - ЕВС), разработанного при участи ФСБ России, ФСТЭК России и Минкомсвязи.

Архитектура решения представлена ниже

Основные компоненты решения:
·         Единое встроенное СЗИ нижнего уровня – встраивается в исполнительные устройства, банкоматы, датчики, счетчики, иные аппаратные и технологические устройства
·         Единое встроенное СЗИ среднего уровня – встраивается в телекоммуникационное оборудование, программируемые логические контроллеры, оборудование промышленных сетей передачи данных
·         Единое встроенное СЗИ верхнего уровня – встраивается в АРМ пользователей и операторов, серверы, промышленные серверы
·         Серверы управления (C&C) – иерархическая структура серверов управления любой сложности

Основные функции решения: управление доступом, контроль целостности, регистрацию событий, антивирусную фильтрацию, межсетевое экранирование, подпись и шифрование по ГОСТ информации, защита от утечек, поведенческая аналитика (UBA). Серверы управления обеспечивают мониторинг ИБ, интеграцию с сервисами киберразведки (Threat Intelligence), с ГосСОПКА, автоматическую разработку ОРД и ознакомление с ними пользователей.

Решение получило сертификат ФСТЭК России на соответствие требованиям МЭ, АВЗ, СОВ, ОС, а также положительное заключение ФСБ России на встраивание в любое российское оборудование и ПО – что полностью покрывает все требования по безопасности ПДн, ГИС и КИИ.
Решение поступило в продажу 1 апреля 2019 г. и доступно для загрузки с download сервера ЕВС.


четверг, 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: Ссылки на другие полезные документы: