15.10.2019

Приоритезация инцидентов ИБ: все не так просто

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


Как бы вы поступили в таком кейсе? Посчитали бы вы такую ситуацию инцидентом ИБ или отнесли бы в разряд чисто айтишных проблем (ну по крайней мере, пока не появится больше деталей)? Возможно, тут сыграл эффект погружения (раз мы на киберучениях по ИБ, то и все кейсы про ИБ, несмотря на то, что я с самого начала сказал, что могут быть подвохи и некоторые кейсы могут быть случайными или не имеющими отношения к ИБ), но большинство команд посчитало, что такое описание однозначно говорит о том, что в компании инцидент ИБ и его надо передавать от службы поддержки в службу ИБ, которая и должна проводить расследование инцидентов. Последующие несколько кейсов лишний раз продемонстрировали, что далеко не всегда компании могут с четкостью определиться с тем, что относится к инцидентам (даже те, кто "ходит" под Банком России с его  ФинЦЕРТом или под ГосСОПКОЙ с НКЦКИ).

Но дело даже не в этом, а в том, что все инциденты ИБ считаются равнозначными. Я неоднократно в рамках киберучений задавал вопрос о том, надо ли на основе полученной информации изменить приоритет инцидента или нет. И судя по многочисленным ответам и не только на этих киберучениях, это оказалось достаточно распространенной проблемой. Но если вдуматься, мы же понимаем, что не все инциденты одинаковы. Например, заражение шифровальщиком ПК секретарши или сервера АСУ ТП, утечка 5000 записей о клиентах или 60 миллионов, простой на 1 час или на неделю... Как минимум, по уровню ущерба инциденты сильно отличаются друг от друга. Я в мае уже писал про варианты оценки ущерба от инцидентов ИБ. Это один, и самый популярный, пожалуй, из вариантов классификации инцидентов ИБ. Градации вы можете определить самостоятельно - обычно их пять, но это число может быть и три, и шесть, и семь, и девять. В зависимости от направления бизнеса и варианты ущерба могут быть разные.


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


Приоритет инцидента будет влиять и на режим работы группы реагирования. В масштабных кейсах этот режим скорее всего будет круглосуточным, а для мелочи можно по-прежнему работать в режиме 5х8.


Приоритет вообще сильно влияет на временные параметры, связанные с инцидентом. Проводить ли расследование в выходные или нет? Работать ли в праздники? В течение какого времени инцидент должен быть взят в работу, а в течение какого кейс должен быть закрыт. Это в свою очередь будет влиять на стоимость расследования и реагирования. Конечно, если компания следует Трудовому Кодексу и оплачивает сотрудникам внеурочную работу, работу в праздники и выходные. На алтайских киберучениях вопрос о том, как компания будет справляться с инцидентом во внерабочее время вызвал недоумение и едкие комментарии, что ИТшники и ИБшники имеют ненормированный рабочий день, но при этом сверхурочные никак дополнительно не оплачиваются :-( И профсоюза у ИБшников нет, чтобы отстаивать их интересы :-(


В процессе киберучений, на вопрос о том, что вы будете делать, если стал недоступен один из файлов на расшаренном ресурсе и компьютеры стали подтормаживать, прозвучал очень необычный для меня ответ, что надо просто выключить все компьютеры и сетевые сервера и проводить расследование. В последующих кейсах я задавал вопрос о том, кто должен принимать решение - об отключении компьютеров, о взаимодействии со СМИ, о необходимости эскалировать инцидент и т.п. Интересно, что большинство участников различных киберучений обычно возлагают всю ответственность за принятия решений на руководителя службы ИБ (даже за отнесение множества связанных событий ИБ к инцидентам). Но приоритет нам подсказывает и лицо, которое должно принимать то или иное решение.


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

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

14.10.2019

Вас шантажируют утечкой данных. Что делать?

Весной 2019-го года, на CISO Forum, я проводил киберучения, где среди прочего был и такой кейс - вы получаете сообщение через соцсети (чат в Facebook Messenger, Telegram, Whatsapp, Viber и т.п.) от человека, который называет себя известным в отрасли ИБ именем и который заявляет, что нашел в Darknet доказательства утечки у вас базы данных. Он, разумеется, готов вам помочь провести расследование данного инцидента. Следующий кейс - этот же человек публикует в открытом доступе информацию об утечке в вашей компании и вы сталкиваетесь с запросами со стороны СМИ.


На прошлой неделе, на Алтайском ИТ-форуме, я проводил очередные киберучения и вновь включил в них этот кейс, чтобы проверить, насколько компании готовы реагировать на такую ситуацию, с которой они могут столкнуться в реальности. Тем более, что за день до этого в СМИ банки "обвинили" одну из российских компаний по ИБ в "ИБ-шантаже". Ведь это вполне логично, задаться вопросом: "А как бы я поступил в такой ситуации?" И задавать его надо применительно к своей организации, а не "вообще". Тем более, что утечки перестали быть чем-то из ряда вон выходящим и факты об этом становятся известными постоянно. Вон на днях в Darknet  стали продавать данные 92 миллионов бразильцев.

Вот представьте, что пока вы читаете эту заметку, к вам пришло сообщение о том, что ваша база клиентов утекла и ее продают в Darknet? Что вы будете делать? Если собрать все, что звучало в рамках киберучений (не только двух упомянутых) и добавить кое-что от себя, то вырисовывается следующий набор действий, который надо делать в таких ситуациях.

Во-первых, если с вами говорит кто-то известный или представитель известной ИБ-компании, то стоит проверить, что с вами связывается именно то лицо, чье имя указано в выходных данных вашего контакта? Во-вторых, стоит проверить, что это не информационная атака, которая направлена против вас. В-третьих, стоит начать внутреннее расследование (возможно с привлечением внешних компаний), которое подтвердит или опровергнет факт утечки. В-четвертых, стоит уведомить руководство компании о факте "шантажа". В-пятых, стоит быть готовым к общению со СМИ (о том, как это делать, я уже писал 3,5 года назад). В-шестых, в зависимости от характера утечки и содержащихся в ней данных, может потребоваться уведомить как самих пострадавших клиентов, так и регуляторов (РКН, ФинЦЕРТ, ГосСОПКА, GDPR и т.п.). Наконец, необходимо будет извлечь уроки и внести изменения как в систему защиты (если факт утечки подтвердится), так и в план реагирования на инциденты.

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

07.10.2019

Применение роботов (платформ RPA) для кибербезопасности

В сентябре на Хабре я написал большой материал про мониторинг ИБ облаков (первая и вторая части). Среди прочего я описывал достаточно частую ситуацию, встречающуюся у облачных провайдеров. Журналы регистрации событий доступны, но выгрузить их можно только в ручном режиме - сформировать лог за интересующий временной интервал и скачать к себе на компьютер  в виде таблички Excel или CSV-файла. При этом делать это на регулярной основе непросто и можно в какой-то момент времени забыть сделать выгрузку, потеряв часть данных для анализа. Можно ли автоматизировать выгрузку таких данных при полном отсутствии API?


Оставим пока в стороне ответ на этот вопрос. Зададимся другим. Точнее я им задавался достаточно долгое время, наблюдая за реализацией сервиса CAPTCHA на разных сайтах. Какое-то время считалось, что этот простой механизм позволяет отсечь ботов и пройти его может только человек. Но если посмотреть на то, как реализуется CAPTCHA, то будет понятно, что мы всегда повторяем одни и те же действия - вводим увиденный на картинке текст в соответствующее поле или нажимаем на картинки, показывающие то, что нас спрашивает сервис CAPTCHA (светофоры, машины, вывески, мосты, гидранты и т.п.). Можно ли автоматизировать действия по нажатию клавиш или движению мыши? Ведь в конце концов мы это делаем не сами,  а просто даем команды компьютеру, которые он и реализует. Но куда вбивать текст и куда кликать мышью указывает человек! Да, но эти действия тоже можно автоматизировать. Помогает решить эту задачу технология RPA (Robotics Process Automation), которая позволяет автоматизировать различные процессы, используя настраиваемых программных роботов, имитирующих действия человека за счет взаимодействия с информационной системой и она не видит разницы между роботом и человеком.

Что умеют  роботы RPA? Они работают с Web-формами, приложениями, почтой, документами, базами данных, файлами на диске или в Интернет, которые могут быть преобразованы по заданному сценарию или алгоритму. Такой робот:
  • позволяет снизить число ошибок
  • работает круглосуточно, без выходных и не требует сверхурочных
  • объединяет данные из разных систем, сокращая время на работу с ними
  • легко  подстраивается под изменчивый процесс
  • не требует интеграции в существующую инфраструктуру.
Внедрение робота занимает немного времени - от 2-х дней уходит на изучение процесса, определение необходимых приложений и ИС, с которыми нужно работать, и снятие скриншотов действий пользователя. От 5-ти дней уходит на настройку робота - сценариев его работы и взаимодействия с нужными системами. От 3-х дней уходит на тестирование и доработку робота. Для простых случаев автоматизации внедрение робота займет около 10 дней - в более сложных может понадобиться 1-2 месяца.


Теперь вернемся к первоначальной задаче. Робот справляется с ней элементарно - будучи установленным на компьютере пользователя или на сервере, он сам через заданные интервалы сгружает журналы регистрации из облачной платформы и преобразовывает в нужный формат и подгружает их в ваш SIEM. Ту же задачу можно было бы возложить на скрипт, написанный на каком-либо языке программирования, но только при условии, что вы умеете это делать, и ваше облако поддерживает API, который можно вызывать из скрипта. В противном случае вы не сможете сделать ничего. А вот робот не  требует ни знаний программирования, ни наличия API. С помощью визуального конструктора (схожая идея реализуется в различных SOAR) вы описываете ваши действия, ответы систем и их интерпретацию.

В кибербезопасности RPA может найти достаточно широкое распространение, особенно в российских условиях, когда многие отечественные решения не имеют API и не умеют взаимодействовать между собой. Я попробовал набросать сценарии, в которых могут быть применены RPA: 

  • Заход в личный кабинет ФинЦЕРТ или ГосСОПКА для получения бюллетеней или уведомлений
  • Обогащение событий безопасности из источников TI
  • Заведение тикетов в IRP / SOAR
  • Анализ заявок на предоставление доступа к корпоративным ресурсам
  • Организация фишинговых симуляций
  • Сбор облачных логов в Excel/CSV и загрузка их в SIEM
  • Анализ входящих сообщений от пользователей
  • Работа с унаследованными или legacy системами ИБ
  • Тестирование защищенности Web-приложений
  • Сбор инвентаризационных данных из десятка источников и приведение к единому формату с загрузкой в CMDB
  • Мониторинг Интернет-ресурсов, а также анализ новостей по ИБ и отправка ключевых во внутреннюю рассылку
  • Построение dashboard
  • Получение согласий на обработку ПДн от клиентов
  • Уведомление о нарушении прав субъекта ПДн.
Это неполный перечень, но он достаточно показательный. С помощью RPA можно автоматизировать многие рутинные задачи, возникающие в деятельности ИБ. Кто выпускает RPA-платформы? Вот список некоторых вендоров, которых можно встретить в России, - UiPath, Automation Anywhere, Blueprism, WorkFusion, Pegasystems, NICE, Kryon, Kofax, Contextor, Softomotive, Redwood Software, EdgeVerve, Another Monday, Antworks, Toughtonomy, SAP iRPA, Datamatics Trubot, Jacada, NTT-AT, Helpsystems, Servicetrace, Robin, PIX, HyperUp, electroNeek.