понедельник, 12 августа 2019 г.

ПДн. Можно ли совместить эффективную систему защиты с выполнением требований?


Часто сталкиваюсь со следующими вопросами:
·        Какими сертифицированными СЗИ можно защитить web-сайт с ПДн?
·        А стоит ли вообще обрабатывать ПДн на сайте, ведь его нельзя защитить в соответствии с требованиями законодательства?
·        Можно ли совместить создание эффективно работающей системы защиты с выполнением требований законодательства?
·        А небольшим компаниям (школы, турфирмы, гостиницы, стартапы) тоже нужно делать вот это ВСЕ?
·        А модель угроз вообще нужна? По какой методике надо делать?                и подобные

В прошлый четверг прошел наш совместный вебинар с Ксенией Шудровой (при поддержке RISC и УЦСБ) где я постарался ответить на эти вопросы на примере ИС – web сайта с ПДн.  По задумке Ксении нужно было дать общие принципы поиска ответов и решений, поэтому постарался рассмотреть несколько возможных вариантов действий и для каждого привел примеры или ссылки, где можно почитать и посмотреть, чтобы окончательно разобраться в теме. В конце обсуждали актуальные вопросы слушателей.
Ксения в своей части рассказывала свежую информацию про изменения в проверках Роскомнадзора и рассматривала интересные примеры из судебной практики по ПДн (я таких ранее не видел).



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

среда, 31 июля 2019 г.

ПДн. Межблогерский вебинар по защите ПДн


Вчера в Роскомнадзоре прошел день открытых дверей по ПДн, который показал, что вопросов у слушателей много, но не все РКН отвечает, некоторые вопросы предпочитает не замечать, а некоторые не в их сфере компетенции.

Не всегда официальная информация от регулятора понятна слушателям


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

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

Вебинар пройдет 08.08.19 15:00-16:00 мск. Ссылка для регистрации.

PS: Видео записи официальных выступлений РКН с дня открытых дверей можно посмотреть тут. Спасибо Листку бюрократической защиты информации и Валерию Комарову за опубликованные материалы


понедельник, 22 июля 2019 г.

ИБ. Канарейки на службе ИБ


Идея использовать “канареек” в информационной безопасности – не новая, но в РФ все ещё редко применяется, поэтому решил напомнить читателям про эту идею.
Эксперты по ИБ предупреждают что защититься от 100% кибератак невозможно – всегда может найтись слишком доверчивый пользователь, непубличная уязвимость или целевая атака. Основной смысл решения с “канарейками” в том, чтобы вместо поиска вторжений в миллионах событий (иголки в стоге сена), мы получили уведомление, когда злоумышленнику всё-таки удалось добраться до нашей ценной информации.

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

В целом идея похожа на honeypot, но только размещение “канареек” должно происходить максимально просто – в пару кликов. С https://canarytokens.org буквально за пару часов мы можете создать и пристроить птичек – а потом целый год пожинать плоды. Посмотрим на несколько примеров:
·        Если у вас активно используется обмен ценной информацией через сетевые папки, то вы аналогично можете создать новую папку с похожим привлекательным названием, запретить к ней доступ обычных пользователей, оставить доступ административных или системных учетных записей.
Далее создаем канарейку / токен типа Windows folder (работает с использованием desktop.ini) и размещаем его в целевой папке.


После того как кто-то заходит в папку, получаем подобное уведомление

·        Если ценные данные ИС размещаются в базах данных, будем селить “канарейку” в БД.
Создаем токен типа SQL Server – для него придумаем новый VIEW с привлекательным названием, который не используется в реальной работе, но к которому будет доступ у любой учетной записи.
 
Применяем полученный скрипт в SQL сервере

Как только злоумышленник проберется в базу и посмотрит наш view, мы получим уведомление

·        Ценная информация отправляется контрагенту в формате word и pdf, но нужно проконтролировать чтобы она не распространялась слишком широко, или не использовалась дольше чем указано в договоре (как это работает обсуждалось тут)
Создаем токен типа Microsoft Word Document или Adobe Reader PDF document

Вставляем в него нашу информацию – отправляем.
Получаем следующие уведомления.


·        У нас есть ценный сайт, который может быть склонирован злоумышленником, и использован для фишинговой атаки на пользователей.
Создаем канарейку типа Cloned web site

Размещаем java-скрипт на странице с авторизацией или там где пользователь вводит данные
При появлении клона сайта получаем уведомления

·        У нас есть ценное web приложение. В каком-то из закрытых разделов, где нет доступа пользователей размещаем привлекательный файл – канарейка типа Adobe Reader PDF document, либо на закрытой web странице размещаем специальные картинки, ссылки либо редиректы – канареки типа URL token, DNS token, Custom Image token, Fast Redirect.  
Пользователи, а этот раздел не ходят, а злоумышленник проберется через уязвимость и посмотрит.

Кому понравилась данная тема и хочется большего, смотрите полноценные honeypot проекты где нужно самим создавать и настраивать приманки; также можно развернуть у себя “канареечный” сервер с кастомным именем – ведь злоумышленики могут блокировать стандартное canarytokens.org; также можно приобретать многофункциональных “канареек”, которые из коробки могут прикидываться АРМ на windwos, маршрутизатором или Linux сервером.

Ps: Для эксперимента по точности обнаружения можете скачать и открыть у себя pdf файл  - потом опубликую что обнаружилось




вторник, 9 июля 2019 г.

КИИ. Методические рекомендации от Ассоциации документальной электросвязи



разработан рабочей группой АДЭ "Методологические аспекты обеспечения безопасности критической информационной инфраструктуры" с участием специалистов ПАО "МегаФон", ПАО "Вымпел-Коммуникации", ПАО "Мобильные ТелеСистемы", ООО "Т2 Мобайл", ООО "НТЦ "Вулкан" и других организаций-членов АДЭ (приятно что не забыты герои, но хорошо бы ещё имена указывать). Документ согласован ФСТЭК России и 8-м Центром ФСБ России и может использоваться операторскими компаниями связи.

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

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

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

Выводы:
·        Возможно, не стоило нагружать максимально широкий круг субъектов КИИ задачами по анализу процессов, выявлению критических и оценке вреда?
Может быть надо было весь этот анализ провести Регулятору совместно с рабочими группами, а с субъектов КИИ спрашивать самые простые вопросы (по аналогии с тем, что привел выше)

·        Субъекты КИИ из других сфер (не связи) также могут подчерпнуть что-то полезное из этого документа (раз уж он согласован с ФСТЭК и ФСБ):
o   Формулы для оценки ущерба бюджетам РФ + пороговые значения для федерального бюджета





o   Обоснование неприменимости ряда показателей

o   Модель нарушителя (хотя по моему мнению она слишком суровая)


o   Перечень основных угроз ИБ (он из базовой модели угроз КСИИ от 2007 г., хотя по моему мнению он слишком древний и мне больше нравится перечень основных угроз из проект методики ФСТЭК от 2015 г.)



вторник, 21 мая 2019 г.

ИБ. Перспективы банка уязвимостей ФСТЭК на PHDays


С ФСТЭК в секции на PHDays 2019 обсуждали вопросы уязвимостей с техническим ИБ сообществом. Показали статистику за последние годы – 2х кратный рост в год.

 В середине прошлого года ФСТЭК опубликовали регламент раскрытия уязвимостей. Это не обязательный документ, но в общем он показывает типовой сценарий действий участников раскрытия уязвимостей. При необходимости и обосновании сроки могут продлеваться.



Более плотную работу с вендорами начали именно после принятия регламента. Сейчас есть более 60 уязвимостей «нулевого дня» по которым вендоры долго не реагируют – в ближайшее время будут публиковать без отработки вендором (в урезанном объёме).

ФСТЭК жаловался, что в 2016 году разработали стандарт по безопасной разработке, а к 2019ому можно по пальцам пересчитать количество компаний, задекларировавших его применение.

В рамках обсуждения от участников звучали идеи:
·       указать на сайте ФСТЭК контактов вендоров для оперативной связи при обнаружении информации об уязвимости (что-то подобноенедавно предлагал в блоге)
·       убрать пункт об отказе вендора в устной форме
·       включить в НПА к операторам и лицензиатам сообщать об уязвимостях
·       иногда когда раскрывается уязвимость в продукте одного вендора не учитывается возможность наличия аналогичной уязвимости в продуктах другого вендора

Ответы на заранее подготовленные и живые вопросы от аудитории:
·       откуда берут данные? из открытых источников с использованием ИИ, также из анализа исходного кода
·       как обеспечат качественный анализ уязвимостей для сертифицированных СЗИ – будут повышать требования для спецов испытательных лабораторий; подготовили специальный курс
·       какие риски у исследователей? Для занимающихся противоправной деятельность – есть риск
·       заимствование информации? Оно конечно есть, особенно по западным вендорам; но есть и уникальный контент, особенно по российским производителям
·       кто проверяет актуальность информации? ФСТЭК, их институт, привлекаемые организации
·       будет ли связь уязвимостей с угрозами? Да, но в этом году будут прорабатывать структурирование угроз (видят недостатки), а в следующие уже будут делать связь с уязвимостями
·       что с проектом методики моделирования угроз от 2015? Когда утвердим узнаете. Задача есть, сроков назвать не могу.   На конференции большое количество специалистов, которые и без ФСТЭК знают, как моделировать угрозы.
·       как происходит сертификация Windows 10? Никак. Обратитесь к разработчику Microsoft – они вам подскажут. Позиция ФСТЭК до них доведена. Проблема в сборе телеметрии.


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

ИБ. Обзор защищенности российских web сайтов


Пару недель назад обновилась до версии 1 достаточно интересная утилита wafw00f. Она позволяет определить каким межсетевым экраном уровня приложения (web application firewall или WAF) защищен web сайт. Поддерживается 112 WAF.

Принцип работы достаточно простой, работает быстро:
·         Отправляем нормальный http запрос
·         Отправляем несколько заведомо подозрительных http запросов, которые WAF (если присутствует) обязан заблокировать
·         По реакции (код ошибки, заголовки, изменение версии web сервера) web сервера / WAF пытаемся определить какое средство защиты используется.

Необходимость применения WAF для защиты важных web ресурсов уже давно осознаны, в БДУ ФСТЭК России есть много угроз для web, справится с которыми поможет только WAF, в системе сертификации есть отдельный класс МЭ уровня приложений и даже 3 сертифицированных решения типа Г.

Было интересно посмотреть какая сейчас статистика использования WAF для защиты российских ресурсов. Для TOP 450 российских сайтов по версии Яндекса получилась следующая картинка.   


Применение WAF в РФ
Количество
%
Не используют WAF
391
86,89%
Используют неизвестный WAF или межсетевой экран / IPS с функцией защиты web
37
8,22%
Cloudflare WAF
21
4,67%
CacheWall WAF
1
0,22%

Выводы. Более 85% ресурсов не защищены WAF. Показатель плачевный.
Около 8 процентов используют средства защиты, которое не удалось утилита не смогла определить (возможно PT AF или Континент WAF), что в общем то хорошо, так как злоумышленникам сложнее обойти средства защиты, о которых ничего не известно.    


вторник, 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 – порядок реализации мер начиная с наиболее важных, рекомендации по реализации процедур и использованию решений по автоматизации мер, метрики для контроля эффективности мер.  При этом всё это в общем то не будет противоречить российскому законодательству по ИБ.