09.12.2019

Обнаружение атак двадцать лет спустя

Почти  двадцать лет спустя я написал свою первую книжку по обнаружению атак, которая, до сих пор используется в учебном процессе ряда ВУЗов. При этом ее часто даже сейчас воспринимают как догму, забывая, что за двадцать лет технологии обнаружения атак сильно поменялись, а возможности решений по обнаружению атак не ограничены только классическими IDSами (хотя регуляторы, присвоив аббревиатуры СОВ и СОА вполне конкретным типам решений, сильно подпортили картину).

В одном из недавних проектов по аудиту SOC я столкнулся с этой проблемой. Заказчик в ТЗ на построение системы защиты указал, что необходимо, среди прочего, построить систему обнаружения атак, а проектировщик не долго думая, просто прописал в проекте кучу сенсоров сетевой системы обнаружения атак и все. В рамках аудита, мы выясняли, причину такого решения, и почему проектант даже имеющийся у заказчика Stealthwatch (решение класса Network Traffic Analytics, NTA) не включил в список технологий обнаружения. Разумеется, все остальные варианты обнаружения вредоносной активности также не были рассмотрены проектироващиком, который почему-то посчитал, что обнаружение атак - это только классические сетевые СОВы (СОА), которые появились в то время, когда основным источником при обнаружении атак был сетевой трафик и, иногда, системные логи.

С тех пор ситуация сильно поменялась и к источникам, по которым можно обнаруживать проявления вредоносной активности, добавилось куча всего другого - файлы, Web-трафик, Netflow (и вообще flow-протоколы), URL, домены, активность пользователя и активность приложений. И это еще не полный перечень.

Другая проблема в обнаружении атак в том, что эти решения обычно ставят на периметра корпоративной или ведомственной сети, в то время как они сегодня давно не ограничены одной площадкой или одним выходом в Интернет. У вас есть внутренняя сеть и куча способов проникновения в нее, минуя периметр. У вас есть Wi-Fi, у вас есть АСУ ТП, у вас есть облака, у вас есть 4G и еще куча точек и отрезков контроля. Обратите внимание, что я специально упомянул не только точки, которые можно контролировать на предмет вредоносной активности, но и отрезки, на которых это можно сделать.

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


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

Да ну, фигня это все, можете сказать вы. У меня есть МСЭ, СОВ и антивирус, да еще и сертифицированный VPN; зачем мне еще что-то? Они прекрасно справляются со своими задачами. Ну еще WAF куплю в 2020-м. Как вообще вышеприведенную матрицу транслировать в приоритезированный список технологий обнаружения атак, которые надо внедрять в организации? Я бы начал с матрицы MITRE ATT@CK, которая описывает самые распространенные тактики, техники и процедуры киберпреступников. Существует маппинг TTP из нее с источниками данных, позволяющих выявлять плохих парней. Обратите внимание, что на первом месте у нас мониторинг процессов, файлов, параметров командной строки, API, реестра и сетевого трафика. Сетевой трафик вообще на последнем месте в Топ7 источников.


Для упрощения можно посмотреть Топ10 источников данных для мониторинга от Red Canary и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.


06.12.2019

Тенденции киберугроз (презентация)

Вчера выступал на московском "Код ИБ. Итоги", где сначала модерировал пленарную секцию, а потом выступал в секции "Угрозы" с обзором тенденций по киберугрозам. Выкладываю презентацию с нее.



04.12.2019

Экономика решений по инспекции DNS

Вчера наткнулся на интересное исследование по экономической ценности решений по инспекции DNS, которые пока незаслуженно не нашли своего места в портфолио служб ИБ. Может быть дело в том, что для таких решений нет требований у регуляторов?


А проблема при этом есть. Как обычно работает вредоносный код? Сначала пользователь заманивается на фишинговый ресурс или легальный, но зараженный сайт (например, evil.example.com), откуда скачивается инсталлятор вредоносного ПО, который в свою очередь соединяется с другим сайтом (например, bigevil.example.net) и подгружает с него основной функционал в виде различных модулей, коих может быть много. При этом вредоносный код может коммуницировать с командным сервером, расположенным на третьем сайте, например, cc.example.org.


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

По данным Cisco, 92% всех вредоносов используют DNS как канал для получения обновлений, коммуникаций с командными серверами и т.п. Авторы исследования пошли дальше и проанализировали базу Verizon DBIR за 5 лет, содержащую 11079 подтвержденных взломов.  Оказалось, что в трети из них (в 3668) смогли бы помочь средства инспекции DNS и не допустить совершения инцидента. Дальше авторы попробовали оценить сумму предотвращенных потерь и их результаты показывают, что эта сумма составляет около 10 миллиардов долларов США за 5 лет по известным инцидентам. Если посмотреть на общую картину по киберпреступлениям, то согласно оценкам, в 2018 в мире ущерб от них составил от 445 до 600 миллиардов долларов. Дальше авторы делают очень интересное предположение, что средства инспекции DNS могут помочь бороться с третью всех этих киберпреступлений, то есть они могут спасти от 115 до 200 миллиардов долларов в год.

Последнее допущение конечно вызывает вопросы, но вот то, что треть совершенных уже взломов можно было бы предотвратить с помощью решений по мониторингу DNS само по себе интересно.  Есть о чем подумать в контексте перспективности этого подхода.

И возвращаясь к теме экономической ценности, которая упомянута в названии отчета. Увы. Отчет про эту тему говорит достаточно мало, приравнивая к эффективности стоимость потенциально предотвращенных потерь в целом по рынку, что далеко от того, что понимается под эффективностью.

02.12.2019

ИБ без бюджета. 7 сценариев

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


Пилоты

Этот кейс я слышал из нескольких источников, так что можно предположить, что он не такой уж и редкий. Вы заказываете пилот интересного вам решения и живете на нем в течение полугода, а то и года, по окончании отказываясь от продукта. Учитывая, что сегодня на рынке присутствует немало продуктов одного класса, такой подход позволяет не только жить в условиях отсутствия бюджета в течении 2-4 лет, но и прокачать свои навыки при работе с новыми продуктами, что позволяет составить неплохое резюме. Правда, на новом месте работы, "старые" поставщики уже не будут с легкостью организовывать для вас пилотные проекты :-) И да, данный вариант не очень подходит для госорганов, так как в процессе пилотирования не осуществляется передачи прав на средство защиты заказчику, на баланс оно не ставится и доказать, например, во время проверки, что организация себя защищает трудновато.

Разделение бюджета с другими подразделениями

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

Open source

Ну с этим вариантом вроде все понятно - вы используете кем-то уже написанное и выложенное в открытый доступ защитное ПО, которое представлено сегодня огромным спектром вариантов - от SIEM до DLP, от антивируса до системы обнаружения атак, от реверс-инжиниринга вредоносного ПО до threat hunting. За лицензии платить не надо, что отлично укладывается в стратегию "ИБ без бюджета". Однако есть и обратная сторона у open source - у специалистов, работающих с ним, квалификация должна быть гораздо выше, чем при использовании коммерческих решений. А высокая квалификация означает большую зарплату, в среднем выше, чем у традиционного безопасника, знакомого только с лидерами магических квадратов Гартнера. И хотя это совсем иная статья затрат, она в целом тоже может лечь на бюджет службы ИБ, что может сделать этот вариант не таким уж и предпочтительным.

Уход от CapEx в сторону OpEx

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

Встроенные механизмы

Не секрет, что часто безопасники вместо того, чтобы задействовать встроенные в ОС, приложения, СУБД, сетевое оборудование и др. механизмы защиты, стараются купить всяких новомодных штук, которые должны стать серебряной пулей и победить всех хакеров. Однако если мы вспомним Top4 защитных мер согласно австралийским лучшим практикам по ИБ, то к ним будут относиться:

  • создание замкнутой программной среды - возможно реализовать через групповые политики
  • обновление приложений - возможно настроить в самих приложениях
  • обновление операционных систем - не требует отдельных решений, достаточно настроить встроенные возможности
  • ограничение административных привилегий.
Если посмотреть на Топ8, то к упомянутым выше 4-м мерам, добавятся:
  • конфигурация настроек макросов в MS Office
  • включение защитных возможностей приложений (отключение Flash, Java Script и т.п.)
  • ежедневное резервное копирование
  • многофакторная аутентификация.
Пожалуй, только многофакторная аутентификация требует внешних решений, да и то, она может быть реализована с помощью open source решений, например, LinOTP, FreeOTP, Gluu, Aerobase и т.п. Если добавить сюда встроенные механизмы защиты в сетевое оборудование, то можно получить неплохий базовый уровень защиты, который будет отсекать не менее 80-90% всех угроз. Иными словами, закрыть многие вопросы ИБ можно встроенными механизмами защиты и отдельного бюджета на это не потребуется.


Работа с людьми

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

Купоны / скидки / черные пятницы / розыгрыши призов

В выходные закончилась "Черная пятница", которую можно назвать седьмым сценарием обеспечения ИБ без бюджета. Разумеется, наш преимущественно корпоративный рынок с его циклами продаж и длительным процессом заключения договоров мало использует тему, столь привычную для сегмента B2C. Но и у нас бывают различные интересные кейсы. Например, розыгрыши антивирусов на различных конференциях. А недавно, на одной из конференций разыгрывали бессрочную лицензию на Secret Net Studio на 1000 пользователей, VPN-поддержку на АПКШ Континет и лицензию vGate на неограниченное количество CPU. Учитывая, что стоимость софта практически равна нулю (даже на флешку или CD тратиться не надо), то для вендора это ничего не стоит, а для заказчика - возможность получить хоть какое, но решение по ИБ (да еще и сертифицированное). Правда, тут тоже могут возникнуть сложности с оформлением выигрыша и постановкой его на баланс, но это уже второй вопрос.

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

27.11.2019

Новая концепция кибербезопасности - Zero Trust (презентация)

Последний региональный "Код ИБ", который я посетил в этом году, проходил в Самаре, где я рассказывал о новой концепции Zero Trust. О самой концепции я уже написал небольшую заметку, а теперь пора выложить и презентацию.



Есть еще и видео про Zero Trust, но оно с другого мероприятия и включает в том числе упоминания Cisco.

26.11.2019

ИБ в госорганах. Голоса с мест

Этой осенью мне довелось поучаствовать в нескольких региональных мероприятиях по ИБ, на которых я пообщался с представителями госорганов, которые поделились со мной своей болью относительно того, что происходит у них с точки зрения кибербезопасности. А на прошлой неделе на SOC Forum было искрометное выступление представителя Самарского ДИТа, который рассказывал о схожих проблемах. В совокупности набежало на целую заметку.
  1. ВУЗы практически убили специалитет по ИБ, оставив преимущественно магистратуру и бакалавриат. А ФСТЭК в своей нормативке требует специалистов по защите информации. А их в природе больше и не готовят почти ;-( Как выполнить это требование?
  2. Качество подготовки кадров оставляет желать лучшего. Это старая история, но не теряющая своей актуальности. То, чему учат, плохо подходит под новые требования, а то, что подходит, не имеет согласований у регуляторов, что вызывает опасения у представителей госорганов - полученную "корочку" не покажешь проверяющим, которые часто следуют формальным признакам.


  3.  С 1-го января 2020 госы переходят на профстандарты, требующие специалистов (опять) с опытом работы от трех лет. Выпускник не подходит, а реальный спец с опытом 3+ на зарплату в гос не пойдет ;-( А если брать выпускника ВУЗа, то это штраф за нарушение профстандарта. В итоге получается коллизия, которую непонятно как решать. Судя по всему, регулятор в лице ФСТЭК не в курсе происходящих изменений в сфере образования и свои документы под них не обновлял.

  4. Зарплата же в регионах в госорганах оставляет желать лучшего. Найти на такую зарплату специалиста с опытом непросто. И даже 13-я зарплата и премии не всегда сильно выправляют эту ситуацию. Приведенный внизу слайд с SOC Forum вызвал бурю эмоций в соцсетях; особенно ассоциативная картинка слева от сумм денежного довольствия :-(


  5. Лицензия на мониторинг ИБ требует специалиста с опытом мониторинга ИБ от трех лет, который (опыт) может быть получен только при наличии лицензии, который требует специалиста с опытом мониторинга ИБ от трех лет, который... Рекурсия-с... Это старая история, но до сих пор всплывает, так как регулятор не дает четкого и официального (или хотя бы публичного на сайте) ответа.
  6. ФСТЭК в числе ошибок по категорированию ОКИИ указывает отказ в признании субъектами, что у них есть КИИ, или занижение категорий значимости. А почему госы так делают? А денег им никто не дал на выполнение ФЗ-187. Лучше не признать наличие ОКИИ, чем признать и не выполнить ФЗ и сесть по 274.1 УК РФ. Парадоксально, но часто именно такие действия рекомендует региональное управления ФСТЭК своим подопечным (разумеется, неофициально).


    1. Новые требования ФСТЭК не может даже сама ФСТЭК выполнить, а точнее ее региональные управления, часто сидящие в арендуемых помещениях, в которых нельзя выполнить все требования регулятора (в т.ч. и по ГТ). Это тоже старая история - многие требования ФСТЭК пишутся из расчета, что подопечные находятся в собственном здании или помещении, а это не так.
    2. К ГосСОПКЕ все подключились, а от нее уже несколько месяцев никаких уведомлений и фидов не приходит. И в чем тогда был весь смысл? Чтобы ФСБ получила дополнительные права по проверкам?.. На SOC Forum прозвучало предположение, что сотрудники НКЦКИ готовились к выступлению и поэтому им не хватало рук на подготовку бюллетеней :-) А может просто атак не было. Хотя по данным регулятора враг не дремлет - на виртуальных границах обстановка неспокойная.


      1. Российские вендора по ИБ достали. Вместо того, чтобы рассказывать о способах решения проблем, тупо впаривают свои поделия, часто даже повышая цены в условиях отсутствия конкуренции и запугивая требованиями по импортозамещению и обращением в суд или прокуратуру, если госорган не побоится и решит купить зарубежное решение. Часто звучит от госорганов вопрос "что делать, когда российских продуктов вообще нет под нужные требования, а дамоклова меча импортозамещения от плеч никто не отнимал?" Российские вендора только в рекламных листовках аналогичны иностранным решениям. А на деле далеки от того, что они импортозамещают.
      2. Отдельная тема - боль испытательных лабораторий, которые не знают, как реализовывать новые требования по доверию от ФСТЭК. И ладно бы, это был единичный случай, я уже от 6-8 лабораторий это слышал в неформальной беседе.
      Вот такая нерадужная картина вырисовывается. Но мы выстоим! Не в первой!

      25.11.2019

      Измерение эффективности SOC. 3 года спустя (презентация)

      На прошлой неделе я выступал на SOC Forum с презентацией о том, как изменилось за последние три года отношение к измерению эффективности SOC. С этой темой я уже выступал три года назад и вот решил вновь к ней вернуться и посмотреть, что изменилось. В качестве иллюстрации использовал данные отчетов о состоянии SOC от SANS и Exabeam, а также результаты еще неопубликованного обзора по российским SOCам, который проводился в преддверии SOC Forum. Отдельный обзор по форуму я еще напишу, а пока выложу свою презентацию:

      08.11.2019

      Как не ошибиться в выборе SOC-as-a-Service (презентация)

      Вчера выступал на нижегородском Коде ИБ, где рассказывал про особенности выбора аутсорсингого партнера по ИБ на примере SOC-as-a-Service. Выкладываю презентацию (на Slideshare).



      06.11.2019

      Как защищать систему без моделирования угроз?

      Сегодня совпало три события, которые и повлекли за собой написание этой заметки. Во-первых, я читал сегодня вебинар по концепции Zero Trust (если вдруг интересно, то вот ссылки на  материалы и видео). Во-вторых, а сейчас изучаю проект новой методики ФСТЭК по моделированию угроз, которая должна быть утверждена до конца года. Наконец, среди интересного проскочила новость, что исследователи нашли способ взламывать Siri, Alexa, Google Assistant с помощью лазера, который внедряет команды, заставляющие голосовых помощников открывать двери, заходить на сайты, запускать и разблокировать автомобили и т.п.

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

      По сути мы являемся заложниками подхода, который заключается в том, что сначала мы моделируем угрозы, а потом разрабатываем меры их нейтрализации и никак иначе. Это даже в нормативной базе прописано. Но что делать, когда у вас не хватает квалификации для этого или система меняется достаточно оперативно, чтобы постоянно вносить правки в модель угроз? Именно в таких условиях и родилась концепция "нулевого доверия" или Zero Trust, появившаяся в 2010-м году у компании Forrester.

      Первоначально она развивала идеи термина "депериметризация", родившегося ранее на Jericho Forum, и касавшаяся только сетевой составляющей. В оригинальную модель Zero Trust входило три компонента, которые позволяли повысить уровень защищенности, не доверяя статическим правилам на МСЭ, коммутаторах и точках доступа. 

      Позже к ней добавили еще ряд компонентов, направленных на более высокий уровень - приложения, пользователей и данные.


      Концепция Zero Trust исходит из того, что мы предполагаем, что угроза может исходить откуда угодно и все их заранее мы никогда не опишем и не приоритезируем. А, следовательно, надо выстраивать принцип минимума привилегий на уровне сети, приложений и пользователей, при этом обеспечивая не статическую, а динамическую политику безопасности, стремясь к непрерывной верификации тех же сетей, приложений, пользователей и данных.

       Это краткое изложении концепции Zero Trust, которая сейчас реализуется многими компаниями, - Cisco, Illumio, Okta, Google, Intel, Akamai, MobileIron и т.п. Но этот, достаточно инновационный подход для многих российских компаний врядли так быстро займет свое место на нашем рынке. Требования регуляторов по моделированию угроз и от него никуда не деться. Поэтому придется совмещать первое со вторым.

      05.11.2019

      Киберучения на SOC Forum 2018 (видео)

      BIS TV выложило на своем канале в YouTube запись прошлогодних киберучений, который я вел на прошлом SOC Forum 2018. Меня многие спрашивали то презентацию с них, то примеры сценариев, и вот теперь есть возможность увидеть не только это, но и саму процедуру их проведения. В обычной жизни они проходят не так пафосно и пишутся под конкретную организацию, но и данное видео очень неплохо показывают всю концепцию и ее реализацию.


      ЗЫ. Остается всего две недели до нынешнего форума

      27.10.2019

      Кибербезопасность медицинского учреждения: взгляд с точки зрения бизнеса

      На прошлой неделе по приглашению Руслана Юсуфова из Mindsmith пригласил меня на "Открытые инновации" (которым впору называться "Открытые просторы" исходя из места проведения) выступить в секции про кибербезопасность медицинских учреждений. Учитывая небольшую длительность, количество участников и формат, я не смог систематизировать все, что я хотел сказать. Поэтому вынесу это в формат заметки для блога.


      Часто между кибербезопасностью медицинских учреждений и защитой персональных данных ставят знак равенства, считая, что именно это является основной задачей медиков, не допустить утечки наших с вами историй болезней, диагнозов, результатов анализов и т.п. Но, не ставя под сомнение данную задачу, все-таки хотел бы обратить внимание, что массовые утечки по сути своей не представляют собой серьезной угрозы, так как клиника от нее мало что теряет. Штраф от РКН? Ну мы не дети, понимаем, что это несерьезно. Снижение лояльности пациентов? Так они уже привыкли к "своим" врачам и врядли будут менять клинику только по причине утечки. Особенно если в округе клиника всего одна или вы приписаны к ней по страховке. GDPR? Ну в России эта страшилка вообще не работает.

      По сути речь идет о попытке обосновать нужду в ИБ опираясь на три составных части, которые "заинтересованы" в атаках и защите от них - пациенты, регуляторы и хакеры. Но как мы уже поняли, первым двум категориям в целом ИБ не так уж и важна. А третья... А что третья? Как она может монетизировать атаки на медицинские учреждения? Социнжиниринг? Может быть, но маловероятно, так как что можно заставить сделать пациента, которому представились представителем его медучреждения? Повторно сдать анализы?


      Но... давайте посмотрим чуть шире и попробуем встать на место конкретного пациента, который ходил не только в поликлиники по врачам, но и может лечь в стационар на 2-3 недели. Что можем ему помешать "насладиться" лежанием в больничной палате? Отсутствие Wi-Fi, выведенного из строя хакерской атакой? Может быть, если речь идет не о Москве с его безлимитным LTE. Подмена лекарств или рецептуры в электронной карте больного? Тоже может быть. Но пока не в России, где электронные карты - еще редкость. Шантаж родных, близких и знакомых разглашением факта "плохой" болезни? Да, вполне. В свое время представители РКН и Госдумы именно под этим соусом продвигали ФЗ-152 в его жесткой редакции. Еще утечка может быть актуальной в тех случаях, когда среди пациентов есть всяческие селебрити - звезды шоу-бизнеса, чиновники, телеведущие и т.п. Из информации об их болезнях можно сварганить репортаж, который привлечет массу людей, рекламодателей и т.п. Вспомните, непрекращающуюся последние пару месяцев эпопею с "болезнью" Заворотнюк...

      А что клиники? Утечка их клиентской базы может повлиять на... доходы. Ведь конкуренты, украв базу пациентов, могут сделать им более выгодные предложения, переманив к себе. При условии, что в округе есть не одна клиника и они конкурируют между собой. В такой ситуации какое-то количество клиентов может все-таки уйти к конкурентам. Но это опять же только в крупных городах, где конкуренция среди клиник достаточно высока. Чему еще может угрожать инцидент ИБ, ставший достоянием гласности? Снижением репутации? Только если это попали на федеральные СМИ (тогда это еще и потеря новых клиентов и стратегических партнеров). А вот если клиника ведет какие-то исследования, за которые платят деньги, то утечка их результатов может быть на руку многим. Конкуренты получают за меньшие деньги то, на что потрачены гораздо большие ресурсы. Заказчики исследований тоже теряют и могут отказаться от продолжения сотрудничества. Еще одним мотивом задуматься о кибербезопасности клиники могут стать затраты на восстановление данных, потерянных в результате кибератаки. Фотография в начале заметки, кстати, посвящена как раз такому событию. Пока в России нет практики, обязывающей сообщать клиентам об инцидентах с их данными, а на Западе - это достаточно большая статья расходов (до 20 долларов на контакт с 1-м пациентом). Я не слышал о таких историях, но допускаю, что в особо вопиющих случаях такое может произойти - смена клиник в рамках договоров ДМС, что влечет за собой еще большие потери для медиков.


      Есть еще одна категория заинтересованных в медицинской ИБ лиц. Это производители медицинского оборудования, взлом которых влияет и на пациентов, их жизнь и здоровье, и на клиники, простой оборудования от шифровальщика может повлечь снижение доходов, и на производителя, которого могут наказать регуляторы (например, в США) или чьи заказы могут сократиться.

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

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

      23.10.2019

      Запор Ярилы, стезя педагогона или старославянский словарь импортозаместителей от ИБ

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

      Вначале приведу список слов, которые могли бы стать названиями или частью названий продуктов по ИБ - градеж, забрало, заклеп, затвор, запор, оплот, твердыня и столпостена. Все эти слова имеют отношение к ограждению, защите или безопасности. Как могло бы звучать название компании "PT Security"? "Благая твердыня" или "Благой оплот" :-) А "Solar Security"? Например, "Запор Ярилы" (Ярила - это славянский бог солнца, а запор - это от глагола запирать) или "Забрало Ярилы" :-) А вот наезды или хула на Solar Security могли бы называться коротким "обсолонь", то есть движение против солнца.

      Какие еще у нас могут быть применимы слова старославянского языка в кибербезопасности? Вот список, например, для английских слов, столь популярных в лексиконе отечественных безопасников:
      • backdoor - афедрон
      • blackholing - хлябь
      • Cisco - лепота
      • CISO - воевода, стража, стратиг, стратилат
      • compliance - путы 
      • CTF - палестра, ристалище 
      • dlp - брещи
      • Huawei - стезя педагогона
      • Infosecurity Russia - позорище 
      • SIEM - многоочитый 
      • SOC - чертог.

      А теперь список англицизмов и соответствующих им посконно русских синонимов:
      • админ, оставивший сервер ElasticSearch в открытом виде - кукомоя
      • атаковать - уязвлять 
      • блокчейн - пленица 
      • безопасник - поборник 
      • бумажный безопасник - законник
      • вирусная эпидемия  - проказа, лепра 
      • деятельность без лицензии - забобоны
      • идентификатор - ипостась
      • инсайдер - афарим, сходник
      • инцидент - тля 
      • киберпреступник - окаянный, пакостник, тать 
      • конфа по ИБ - глумилище
      • кража - татьба 
      • тайновидец - криптограф 
      • лицензия - вериги
      • место для лицензий регуляторов - красный угол 
      • метрика - литра, мерило 
      • межсетевой экран - мандра (это еще и названием собственным может стать), вратарь, вратник
      • облако - мгла, морок 
      • оплата аутсорсинговых услуг - оброк
      • отказ системы - долгонедужие
      • патч - плат 
      • последователи реальной безопасности, отрицающие ФСТЭК и ее требования - штундисты 
      • реестр российского ПО Минкомсвязи - буява
      • рынок сертифицированных средств защиты информации - вертеп
      • система обнаружения вторжений - мрежа, бредень
      • сотрудники службы ИБ - челядь
      • социальный инжиниринг - искушение
      • требования по ИБ - умовредие
      • уязвимость - язва
      • фейковый аккаунт - личина, харя, лярва
      • ФинЦЕРТ - нощный вран
      • фишинговые учения - козни
      • фишинг - прелесть 
      • ФСТЭК - доилица, кормило 
      • хакер - супостат, боритель
      • чиновник - косноязычный 
      • штраф за нарушение требований по защите информации - епитимия
      • 8-й центр - капище
      Обладая таким словарем можно уже спокойно найти патриотические аналоги столь привычных нам названий наших компаний и продуктов по ИБ:
      • Infowatch - Инфоглядун, Инфосоглядатай или Инфооко
      • Secret Net - Тайный Невод
      • ViPNet - Знатный Невод
      • DIONIS - Корс (это уже не греческий, а славянский бог пьянства)
      • Secret Studio - Тайная светлица
      • Комрад - Товарисч
      • UserGate - Холопские врата
      • Мастерчейн - Гривнозлатарь
      • Перспективный мониторинг - Узреющая ворожения.
      Согласитесь, так все звучит гораздо лучше и в русле взятого в России на хоругвь импортозамещения в области кибербезопасности. Получив основы старославянского языка, дальше вы можете и сами переложить отечественные ИБ-названия на язык, который скоро может вернуться в обиход.


      21.10.2019

      Эскалация инцидентов ИБ

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


      Что нас может не устраивать? Аналитик не справляется с работой в заданное в SLA время? Извините, но тут не может быть никакой эскалации. Это неприятно, это требует внимания со стороны руководителя дежурной смены, но это ни в коем случае не должно быть причиной эскалации. А вот если масштаб инцидента оказался больше, чем предполагалось изначально? Например, предполагалась утечка 100 записей о клиентах, а потом оказалось, что утекало 100 тысяч или 10 миллионов? Это, безусловно, причина для эскалации, что потребует привлечения внимания более высокого руководства, чем предполагалось изначально и принятия немного иных мер. В данном случае у инцидента еще и приоритет повысится. Но эскалация - это не всегда повышение приоритета. Оно может сопровождать эскалацию, но не обязательно следует за ней.

      А что еще нас может не устраивать, что повлечет за собой эскалацию? Допустим вас не устраивает, как проводятся работы над вашим инцидентом. Недавно у меня была история. Потребовалась помощь службы поддержки - и я открыл соответствующий кейс. Мне назначили инженера, который пытался связаться со мной в нерабочее время, о чем я ему и сообщил, попросив позвонить с 10 до 18 по Москве. Он сказал "ОК" и пропал. День его нет, второй, третий,  При этом в истории кейса появляются записи, что он никак не может со мной связаться. Ну бывает :-) И хотя ситуация была некритичная, я все-таки в какой-то момент эскалировал ее на руководителя дежурной смены, который "дал пинка" моему инженеру и тот быстро разрешил стоящую передо мной задачу. Иными словами, причиной эскалации стало недовольство тем, как разбирался мой инцидент. И никакой приоритет у него не изменялся - просто мне потребовалось как-то обратить внимание на него. Но тут важно отметить, что причиной эскалации стало не просто мое необоснованное желание ("я хочу"), а мотивированный запрос с объяснением причин эскалации.

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

      Что еще? Допустим с личного ноутбука сотрудника по компании стал распространяться вредоносный код, который при этом не поразил большого количества компьютеров в сети. Вроде бы рядовая ситуация, и приоритет не очень высокий. Но так получилось, что этим сотрудником оказался генеральный директор компании (кстати, реальная ситуация). В этом случае может потребоваться эскалация инцидента, чтобы привлечь к нему внимание руководителя ИБ, которому, возможно, придется  объясняться перед генеральным директором о произошедшем. Кстати, вместо генерального директора может быть и рядовая секретарша, у которой слишком тесные отношения с генеральным, что ставит ее в немного привилегированное положение и требует (такова уж внутренняя политика) немного иного внимания, чем к рядовым сотрудникам.

      Представим, что аналитик SOC получил в работу кейс, но в процессе выясняется, что ему не хватает знаний и кейс выходит за рамки полномочий аналитика. У него нет инструментов для обогащения данных, у него нет доступа к дополнительным инструментам расследования. Что ему остается? Расписаться в собственном бессилии или передать кейс дальше, например, аналитикам следующего уровня (линии)? Второй вариант тоже можно назвать эскалацией, хотя это будет достаточно условно. На мой взгляд это скорее обычный режим работы SOC/CSIRT, чем нечто необычное, что требует привлечения внимания.

      При эскалации одной из важнейших задач является обоснование для нее. Я, как, думаю, и многие люди, не всегда объясняю причины своих поступков, считая, что "все же и так очевидно". Вот в эскалации такая фигня не работает - чтобы эскалация прошла успешно, должна быть веская причина. "Я так хочу", "Это же очевидно", "Я же босс" к таковым не относятся. Интересно, но когда пытаешься внятно сформулировать, зачем тебе нужна эскалация, часто получается, что она и не нужна :-) Если же верно все-таки обратное, то обоснование для эскалации должно быть бизнес-ориентированным. "Данный инцидент может стать достоянием СМИ и надо подготовиться", "Несмотря на стандартные двое суток на решение данного типа инцидента, нам надо его решить к завтрашнему совету директоров", "По результатам расследования стало известно, что утекло не 1000 записей о клиентах, а 1 миллион записей", "Шифровальщик заразил компьютеры бухгалтерии и они не успевают сдать отчетность в налоговую, что может привести к штрафам" и т.п.

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

      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 год назад.